ESC-TR-2007-054 


Project  Report 
ATC-337 


Elementary  Surveillance  (ELS)  and 
Enhanced  Surveillance  (EHS)  Validation 
via  Mode  S  Secondary  Radar  Surveillance 


R.D.  Grappel 
G.S.  Harris 
M.J.  Kozar 
R.T.  Wiken 


23  April  2008 


Lincoln  Laboratory 

MASSACHUSETTS  INSTITUTE  OF  TECHNOLOGY 

Lexington,  Massachusetts 


Prepared  for  the  Department  of  the  Air  Force  tinder  Contract  FA8721-C-05-0002. 
Approved  for  public  release;  distribution  is  unlimited. 


20080501238 


This  report  is  based  on  studies  performed  at  Lincoln  Laboratory,  a  renter 
for  research  operated  by  Massachusetts  Institute  of  Technology.  This  work 
was  sponsored  by  the  Defense  of  Defense  under  Air  Force  Contract 
F  A872 1 -05-C-0002 . 

This  report  may  be  reproduced  to  satisfy  needs  of  U.S.  Government 
agencies. 


The  ESC  Public  Affairs  Office  has  reviewed  this  report, 
and  it  is  releasable  to  the  National  Technical  Information 
Service,  where  it  will  be  available  to  the  general  public, 
including  foreign  nationals. 


This  technical  report  has  been  reviewed  and  is  approved  for  publication. 


FOR  THE  COMMANDER 


Gy'y  Vutungian 
Administrative  Contracting  Officer 
Plans  and  Programs  Directorate 
Contracted  Support  Management 


Non-Lincoln  Recipients 

PLEASE  DO  NOT  RETURN 

Permission  has  been  given  to  destroy  this 
document  when  it  is  no  longer  needed. 


Massachusetts  Institute  of  Technology 
Lincoln  Laboratory 


Elementary  Surveillance  (ELS)  and  Enhanced  Surveillance  (EHS) 
Validation  via  Mode  S  Secondary  Radar  Surveillance 


R.D.  Grappel 
G.S.  Harris 
M.J.  Kozar 
R.T.  Wiken 
Group  42 


Project  Report  ATC-337 


23  April  2008 


Approved  for  public  release;  distribution  is  unlimited. 


Lexington 


Massachusetts 


EXECUTIVE  SUMMARY 


Several  applications  of  the  Mode  S  data  link  are  currently  being  implemented  and  equipage 
requirements  have  been  issued  in  countries  around  the  world.  Elementary  surveillance  (ELS)  and 
Enhanced  surveillance  (EHS)  applications  have  been  mandated  in  Europe  with  full  equipage  of 
all  aircraft  in  the  airspace  required  by  2009.  Exemptions  to  the  ELS  requirement  include  aircraft 
that  will  be  out  of  service  by  31  December  2009,  and  aircraft  undergoing  flight-testing,  delivery, 
or  transit  into  or  out  of  maintenance  bases.  Transport  type  aircraft  (defined  as  having  a  maximum 
take-off  weight  in  excess  of  5700  kilograms  (about  12,500  pounds)  or  a  maximum  cruising 
airspeed  in  excess  of  250  knots)  are  to  be  equipped  to  support  ELS  and  EHS.  Exemptions  to  the 
requirement  for  EHS  include  those  listed  above  for  ELS  and: 

(a)  Fighter  and  training  aircraft; 

(b)  Rotary-wing  aircraft; 

(c)  Existing/older  transport  type  aircraft  undergoing  avionics  upgrades  which  will  then 
support  ELS/EHS;  and 

(d)  Aircraft  types  granted  special  exemptions  (e.g.,  Bl-B,  B2-A,  and  B-52H  bombers). 

The  automatic  dependent  surveillance  via  broadcast  application  (ADS-B,  using  Mode  S 
1090  MHz  squitter  as  the  link)  is  already  in  place  in  some  countries  (e.g.,  Australia)  and  a  notice 
of  proposed  rule-making  has  been  issued  in  the  U.S.  to  require  ADS-B  equipage  in  all  aircraft  by 
2020.  The  United  States  Air  Force  (USAF)  has  taken  notice  of  the  current  and  proposed 
requirements  for  Mode  S  avionics  and  is  actively  equipping  its  fleet  for  the  appropriate  Mode  S 
applications  so  that  its  aircraft  will  conform  to  the  requirements  in  all  airspace  where  they  might 
need  to  operate.  Lincoln  Laboratory  was  tasked  by  the  USAF  to  develop  an  approach  to  avionics 
monitoring  to  ensure  that  its  installed  Mode  S  data  link  avionics  are  operating  in  conformance 
with  the  requirements  of  these  applications.  This  report  was  written  to  describe  the  algorithms 
and  methodology  required  to  determine  conformance  for  the  ELS  and  EHS  applications.  A 
separate  report  is  being  written  for  the  ADS-B  application. 

As  illustrated  in  the  simplified  block  diagram  shown  in  Figure  1,  the  avionics  required  to 
support  the  Mode  S  data  link  applications  consist  of  a  number  of  data  sources,  several  functional 
blocks,  a  Mode  S  transponder,  and  several  data  buses  and  interconnections.  (Note:  the  blocks 
marked  with  an  asterisk  are  optional  and  might  be  combined  with  other  blocks,  e.g.,  the  data 
concentrator/formatter  functionality  might  be  incorporated  into  the  Mode  S  transponder.)  While 
there  are  independent  unit  tests  required  for  each  avionics  block,  what  is  needed  to  ensure  proper 
operation  of  the  complete  system  is  a  test  procedure  covering  the  entire  system. 


Figure  1.  Simplified  Mode  S  Avionics  Architecture. 

One  overall  system  test  methodology  that  has  been  proposed  uses  an  external  test  jig  that 
can  insert  known  data  onto  the  aircraft’s  data  buses.  The  output  of  the  Mode  S  transponder  would 
be  validated  against  the  expected  results  arising  from  the  injected  values.  This  test  methodology 
has  the  following  drawbacks: 

(1)  It  requires  a  specific  knowledge  of  the  buses  and  installed  equipment  on  the  aircraft. 
Differing  procedures  would  be  required  for  different  configurations.  Not  all  USAF 
aircraft  employ  the  same  interconnecting  buses  (or  they  might  not  provide  convenient 
data  ports  for  the  connection  of  the  necessary  test  apparatus).  Aircraft-specific  test 
equipment  might  be  required  (e.g.,  to  bypass  the  aircraft’s  weight  on  wheels  switch). 

(2)  It  can  only  deal  with  one  subject  aircraft  at  a  time.  There  would  need  to  be  considerable 
management  and  scheduling  of  the  test  processing  to  make  sure  that  sufficient  numbers 
and  types  of  aircraft  were  tested. 

(3)  Since  there  are  many  data  items  incorporated  into  the  Mode  S  applications  (and  some  of 
these  data  items  are  inter-related),  it  would  take  quite  a  large  test  set  to  fully  cover  the 
possible  cases.  Unexpected/unanticipated  system  errors  or  failure  modes  might  be 
missed. 

(4)  A  one-at-a-time  test  methodology  is  not  useful  for  monitoring  the  overall  conformance  of 
the  USAF  fleet.  It  would  not  detect  failures  or  anomalies  that  occurred  after  the  testing 
for  the  aircraft  type  had  been  completed  or  which  were  specific  to  a  particular  aircraft. 

(5)  The  end-users  of  the  Mode  S  applications  will  be  validating  the  performance  of  the 
applications  from  actual  flight  operations. 

Responding  to  these  drawbacks  of  testing  compliance  via  data  insertion  (especially  (4)  and 
(5)),  Lincoln  Laboratory  is  developing  a  fleet  monitoring  system  whose  overall  architecture  is 
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shown  in  Figure  2.  A  Mode  S  sensor  on  the  ground  is  employed  to  obtain  surveillance  data  to 
support  construction  of  “truth  tracks”.  The  same  sensor  uses  the  Mode  S  data  link  to  extract  the 
contents  of  particular  transponder  registers  from  the  aircraft  within  its  surveillance.  This 
transponder  register  extraction  protocol  is  entirely  equivalent  to  the  procedure  that  the  actual 
users  of  the  Mode  S  applications  will  employ.  The  monitoring  system  compares  the  extracted 
register  data  with  the  Mode  S  surveillance  data  truth  tracks  and  flags  any  deviations  deemed 
significant.  The  fleet  monitoring  system  can  be  used  to  determine  compliance  for  a  single  aircraft 
(identified  by  its  unique  Mode  S  address),  to  monitor  all  aircraft  in  sensor  coverage,  or  to  validate 
a  range  of  aircraft  in  the  airspace  (e.g.,  all  U.S.  military  aircraft).  The  fleet  monitoring  system 
requires  no  additional  equipment  onboard  the  aircraft  or  within  the  Mode  S  sensor. 
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Figure  2.  Fleet  Monitoring  System  Architecture. 


Note:  it  is  assumed  that  each  component  of  the  individual  aircraft  avionics  has  already 
passed  its  bench  and  ramp  tests.  The  compliance  monitoring  described  in  this  report  is  intended 
as  a  full-system  evaluation  of  the  performance  of  the  Mode  S  data  link  application  avionics. 
Additionally,  some  data  elements  of  specific  applications  may  require  truth  data  that  cannot  be 
obtained  via  the  Mode  S  sensor  surveillance.  For  example,  the  aircraft’s  flight  identification 
would  need  to  be  determined  from  external  sources  (e.g.,  the  flight  plan)  in  order  to  fully  validate 
this  data  field.  As  another  example,  the  Mode  S  surveillance  data  can  be  used  to  determine  the 
aircraft’s  ground  speed  -  but  the  aircraft’s  airspeed  values  are  influenced  by  the  local  winds  (and 
other  factors).  While  it  may  be  possible  to  infer  or  independently  obtain  the  wind  data,  full 
validation  of  the  airspeed  would  require  an  actively  controlled  test  plan  including  the 
participation  of  the  pilot. 
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This  report  is  aimed  at  an  engineering  team  tasked  with  implementing  an  automatic 
analysis  system  to  perform  ELS/EHS  compliance  monitoring.  The  material  covered  in  this  report 
includes  the  following  areas  of  the  ELS/EHS  monitoring  process: 

(a)  Definitions  for  the  data  link  interface  to  a  Mode  S  sensor  and  the  protocols  to  be  used  in 
extracting  data  from  aircraft  transponders; 

(b)  Examination  of  the  avionics  configuration  and  status  information  for  ELS  and  EHS; 

(c)  Examination  of  the  ELS  aircraft  identification  and  ACAS  registers; 

(d)  Computation  of  the  acceptability  thresholds  for  surveillance-based  EHS  data  (e.g., 
ground  speed,  turn  rate)  based  on  the  measurement  accuracy  of  the  Mode  S  sensor  being 
used  for  the  monitoring; 

(e)  Horizontal  and  vertical  tracker  algorithms  (derived  from  Mode  S  applications)  used  to 
derive  velocity  components  from  Mode  S  sensor  target  reports; 

(f)  Algorithms  used  to  check  EHS  airspeed  values  for  consistency;  and 

(g)  Validation  of  the  EHS  register’s  dynamic  values. 

It  should  be  noted  that  the  focus  of  this  report  is  a  compliance  monitoring  system.  This 
report  does  not  include  descriptions  of  such  test  system  components  as  test  director  stations  and 
real-time  data  processing,  or  definitions  of  any  controlled  flight  tests  or  specific  test  scenarios  that 
might  be  deemed  necessary  to  fully  exercise  the  Mode  S  ELS  and  EHS  application  avionics  in  a 
flight  test  environment. 
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1.  INTRODUCTION 


Several  applications  of  the  Mode  S  data  link  are  currently  being  implemented  and  equipage 
requirements  have  been  issued  in  countries  around  the  world.  The  elementary  surveillance  (ELS) 
and  enhanced  surveillance  (EHS)  applications  have  been  mandated  in  Europe  with  full  equipage 
of  all  aircraft  in  the  airspace  required  by  2009.  (See  [1]  for  a  complete  specification  of  the 
European  ELS/EHS  mandate.)  Exemptions  to  the  ELS  requirement  include  aircraft  that  will  be 
out  of  service  by  31  December  2009,  and  aircraft  undergoing  flight-testing,  delivery,  or  transit 
into  or  out  of  maintenance  bases.  Transport  type  aircraft  (defined  as  having  a  maximum  take-off 
weight  in  excess  of  5700  kilograms  (about  12,500  pounds)  or  a  maximum  cruising  airspeed  in 
excess  of  250  knots)  are  to  be  equipped  to  support  ELS  and  EHS.  Exemptions  to  the  EHS 
requirement  include  those  listed  above  for  ELS  and: 

(a)  Fighter  and  training  aircraft; 

(b)  Rotary-wing  aircraft; 

(c)  Existing/older  transport  type  aircraft  undergoing  avionics  upgrades  which  will  then 
support  ELS/EHS;  and 

(d)  Aircraft  types  granted  special  exemptions  (e.g.,  Bl-B,  B2-A,  and  B-52H  bombers). 

The  United  States  Air  Force  (USAF)  has  taken  notice  of  the  current  and  proposed 
requirements  for  Mode  S  avionics  and  is  actively  equipping  its  fleet  for  the  appropriate  Mode  S 
applications  so  that  its  aircraft  will  conform  to  the  requirements  in  all  airspace  where  they  might 
need  to  operate.  Lincoln  Laboratory  was  tasked  by  the  USAF  to  develop  an  approach  to  avionics 
monitoring  to  ensure  that  installed  Mode  S  data  link  avionics  are  operating  in  conformance  with 
the  requirements  of  these  applications.  This  report  was  written  to  describe  the  monitoring 
algorithms  and  methodology  required  to  determine  conformance  for  the  ELS  and  EHS 
applications'. 

As  illustrated  in  the  simplified  block  diagram  shown  in  Figure  1-1,  the  avionics  required  to 
support  the  Mode  S  data  link  applications  consist  of  a  number  of  data  sources,  several  functional 
blocks,  a  Mode  S  transponder,  and  several  data  buses  and  interconnections.  (Note:  the  blocks 
marked  with  an  asterisk  are  optional  and  might  be  combined  with  other  blocks,  e.g.,  the  data 
concentrator/formatter  functionality  might  be  incorporated  into  the  Mode  S  transponder.)  While 
there  are  currently  specific  unit  tests  required  for  each  avionics  block  independently,  what  is 
needed  to  ensure  proper  operation  of  the  complete  system  is  a  test  procedure  for  the  complete 
system. 


The  automatic  dependent  surveillance  via  broadcast  (ADS-B)  application  (using  Mode  S  1090  MHz  squitter  as  the 
link)  is  already  in  place  in  some  countries  (e.g.,  Australia),  and  a  notice  of  proposed  rule-making  has  been  issued  in  the 
U.S.  to  require  ADS-B  equipage  in  all  aircraft  by  2020.  ADS-B  monitoring  is  addressed  in  a  separate  Report. 
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Figure  1-1.  Simplified  Mode  S  Avionics  Architecture. 

One  overall  system  test  methodology  that  has  been  proposed  uses  an  external  test  jig  that 
can  insert  known  data  onto  the  aircraft’s  data  buses.  The  output  of  the  Mode  S  transponder  would 
be  validated  against  the  expected  results.  This  test  methodology  has  the  following  drawbacks: 

(1)  It  requires  a  specific  knowledge  of  the  buses  and  installed  equipment  on  the  aircraft 
under  test.  Differing  test  procedures  would  be  required  for  different  configurations. 
Not  all  USAF  aircraft  employ  the  same  interconnecting  buses  (or  they  might  not 
provide  convenient  data  ports  for  the  connection  of  the  necessary  test  apparatus). 
Aircraft-specific  test  equipment  might  be  required  (e.g.,  to  bypass  the  aircraft’s 
weight  on  wheels  switch); 

(2)  It  can  only  deal  with  one  subject  aircraft  at  a  time.  There  would  need  to  be 
considerable  management  and  scheduling  of  the  test  processing  in  order  to  make  sure 
that  sufficient  numbers  and  types  of  aircraft  were  tested; 

(3)  Since  there  are  many  data  items  incorporated  into  the  Mode  S  applications  (and  some 
of  these  data  items  are  inter-related),  it  would  take  quite  a  large  test  set  to  fully  cover 
the  possible  cases.  Unexpected/unanticipated  system  errors  or  failure  modes  might 
be  missed; 

(4)  A  one-at-a-time  test  methodology  is  not  useful  for  monitoring  the  overall 
conformance  of  the  USAF  fleet  on  a  continual  basis.  It  would  not  detect  failures  or 
anomalies  that  occur  after  the  testing  for  the  aircraft  type  had  been  completed  or 
which  were  specific  to  a  particular  aircraft;  and 

(5)  The  end-users  of  the  Mode  S  applications  are  establishing  a  monitoring  program  to 
determine  aircraft  performance  from  actual  flight  operations. 

Responding  to  these  drawbacks  of  testing  compliance  via  data  insertion  (especially  (4)  and 
(5)),  Lincoln  Laboratory  is  developing  a  compliance  monitoring  system  whose  overall 
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architecture  is  shown  in  Figure  1-2.  A  Mode  S  sensor  on  the  ground  is  employed  to  obtain 
surveillance  truth  for  the  aircraft  (one  or  many).  Simultaneously,  the  Mode  S  sensor  uses  the  data 
link  to  extract  the  contents  of  particular  transponder  registers  from  all  aircraft.  (Note:  this 
transponder  register  extraction  protocol  is  entirely  equivalent  to  the  procedure  that  the  actual 
users  of  the  Mode  S  applications  will  employ.)  The  fleet  monitoring  system  compares  the 
extracted  register  data  with  the  Mode  S  surveillance  data  truth  and  flags  any  deviations  deemed 
significant.  Figure  1-2  illustrates  the  overall  architecture  used  by  Lincoln  Laboratory  to  record 
the  surveillance  and  register  data  for  off-line  analysis.  The  fleet  monitoring  system  can  be  used 
to  test  a  single  aircraft  (identified  by  its  unique  Mode  S  address),  to  monitor  all  aircraft  in  sensor 
coverage,  or  to  validate  a  range  of  aircraft  in  the  airspace  (e.g.,  all  U.S.  military  aircraft).  The 
fleet  monitoring  system  requires  no  additional  equipment  onboard  the  aircraft  or  within  the 
Mode  S  ground  sensor,  with  the  only  requirement  being  the  connection  of  a  modem  to  an  existing 
sensor  interface. 
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Figure  1-2.  Fleet  Monitoring  System  Architecture. 


Note:  it  is  assumed  that  each  component  of  the  individual  aircraft  avionics  has  already 
passed  its  bench  and  ramp  tests.  It  is  assumed  that  the  Mode  S  transponder,  encoding  altimetry 
system  and  ACAS  equipment  (if  one  is  installed)  are  each  performing  to  specification.  The  fleet 
monitoring  described  in  this  report  is  intended  as  a  full-system  evaluation  of  the  performance  of 
the  Mode  S  data  link  application  avionics.  Some  data  elements  of  specific  applications  may 
require  truth  data  that  cannot  be  obtained  via  the  Mode  S  sensor  surveillance.  For  example,  the 
Mode  S  surveillance  data  can  be  used  to  determine  the  aircraft’s  ground  speed  -  but  the  aircraft’s 
airspeed  values  are  influenced  by  the  local  winds  (and  other  factors).  While  it  may  be  possible  to 
obtain  or  infer  the  wind  data,  full  validation  of  the  airspeed  would  require  an  actively  controlled 
test  plan  including  the  participation  of  the  pilot. 
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This  report  contains  definitions  for  the  data  link  interface  to  a  Mode  S  sensor  and  the 
protocols  to  be  used  in  extracting  data  from  an  aircraft’s  transponder.  Algorithms  for  horizontal 
and  altitude  tracking  of  surveillance  data  are  provided  in  order  to  compute  aircraft  velocities  and 
accelerations.  Procedures  are  defined  to  calculate  the  validation  thresholds  for  various  ELS  and 
EHS  data  items  based  on  the  measurement  accuracy  parameters  of  the  surveillance  source.  The 
sequence  of  steps  required  to  evaluate  the  Mode  S  configuration  state  of  an  aircraft  relevant  to  the 
ELS  and  EHS  applications  is  specified.  Finally,  this  report  details  the  validation  processing  for 
each  data  field  in  each  Mode  S  transponder  register  that  is  involved  in  the  ELS  and  EHS 
applications. 

The  focus  of  this  report  is  a  compliance  monitoring  system,  rather  than  an  ELS/EH S>  flight- 
test  system.  Therefore,  it  does  not  include  descriptions  of  such  key  test  system  components  as 
test  director  stations  and  real-time  data  processing,  or  definitions  of  any  controlled  flight  tests  or 
specific  test  scenarios  that  might  be  deemed  necessary  to  fully  exercise  the  Mode  S  ELS  and  EHS 
application  avionics  in  a  flight  test  environment. 

The  intended  audience  for  this  report  is  an  engineering  staff  assigned  the  task  of 
implementing  a  monitoring  system  that  can  determine  ELS  and  EHS  compliance  for  an  aircraft, 
either  for  a  fleet  or  for  a  specific  aircraft.  This  discussion  assumes  that  standard  surveillance  truth 
data  and  Mode  S  ELS  and  EHS  register  data  have  been  acquired  using  a  Mode  S  ground  sensor 
capable  of  extracting  particular  Mode  S  transponder  registers  via  the  Mode  S  ground-initiated 
Comm-B  (GICB)  protocol  [1], 

The  algorithms  described  herein  are  intended  for  either  real-time  or  off-line  (recorded  data) 
operation.  They  are  capable  of  validating  a  large  portion  of  the  ELS/EHS  avionics  installation 
automatically  -  requiring  no  additional  inputs  or  test  procedures.  They  may  involve  a  single 
selected  aircraft  up  to  and  including  all  aircraft  in  the  coverage  of  the  sensor.  Where  additional 
data  are  required  for  a  full  test  of  the  installation  (such  as  flight  identification),  those  inputs  are 
described  herein. 

1.1  References 

Reference  [1]  contains  the  European  ELS  and  EHS  mandate  requirement  specification. 
Reference  [2]  provides  the  full  definition  and  international  standards  for  Mode  S-Specific 
services  including  ELS  and  EHS.  Reference  [3]  provides  a  summary  description  for  the  ELS  and 
EHS  applications  (along  with  the  Automatic  Dependent  Surveillance  via  Broadcast  (ADS-B) 
application). 

Reference  [4]  is  the  source  for  most  of  the  algorithms  used  to  derive  the  measurement 
accuracy  bounds  for  the  various  surveillance  parameters  as  a  function  of  the  sensor  performance. 
Reference  [5]  defines  the  various  data  fields  in  ASTERIX  Category  048  surveillance  output 
format  that  can  be  used  where  available  from  the  supporting  sensor.  Reference  [6]  is  the  source 
of  the  horizontal  and  100-foot  vertical  tracker  algorithms  in  the  appendices.  References  [7] 
and  [8]  provide  the  background  for  these  algorithms. 

Reference  [9]  provides  the  standards  and  test  procedures  for  ACAS  (a  portion  which  is  part 
of  ELS).  In  addition,  it  describes  a  25-foot  altitude  tracker,  as  described  in  Appendix  D. 
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References  [  1 0]  and  [11]  describe  the  relationships  among  the  various  measures  of  airspeed 
provided  by  EHS.  Reference  [12]  illustrates  the  variance  between  magnetic  and  true  north  for  the 
continental  United  States. 

References  [13]  through  [15]  define  the  data  link  interfaces  used  by  the  terminal  Mode  S 
sensors  fielded  in  the  United  States.  References  [16]  and  [17]  define  the  internationally 
standardized  ASTER1X  Category  018  interface  (surveillance  and  data  link  functions). 

1.2  Document  Organization 

Section  2  of  this  report  discusses  the  Mode  S  Communication  Capability,  as  well  as  Static 
and  Dynamic  Configuration.  It  describes  the  process  of  determining  whether  the  transponder  is 
capable  of  supporting  register  data  extraction  and  whether  the  transponder  asserts  that  ELS  and 
EHS  data  items  are  available  via  register  extraction. 

Section  3  introduces  the  algorithms  required  to  determine  the  measurement  accuracy 
derivable  from  radar-based  surveillance  data.  Section  4  addresses  the  3-bit  flight  status  (FS)  field 
contained  in  each  Mode  S  surveillance  reply. 

Section  5  discusses  tests  of  the  ELS  aircraft  identification  function  in  Mode  S  transponder 
register  20|62.  Section  6  discusses  ELS  register  30)6  ACAS  Advisory,  which  must  be  tested  under 
highly  controlled  conditions  using  special  ACAS  test  equipment.  ACAS  tests  should  not  be 

conducted  with  the  aircraft  in  actual  flight;  see  T9L 

Section  7  presents  tests  of  the  five  data  fields  in  the  EHS  Selected  Vertical  Intention 
register  (40|6).  Section  8  discusses  tests  of  the  five  data  fields  in  the  EHS  Track  and  Turn 
register  (50|6).  Section  9  discusses  tests  of  the  five  data  fields  in  the  EHS  Heading  and  Speed 
register  (60|6). 

Appendix  A  of  this  report  gives  the  Mode  S  transponder  register  definitions  for  each 
register  used  by  the  ELS  and  EHS  validation  processes.  The  register  layouts  in  Appendix  A  have 
been  extracted  from  [2];  in  the  event  that  the  requirements  arc  revised  such  that  the  register 
layouts  have  changed,  the  layouts  presented  in  the  latest  version  of  that  document  take 
precedence. 

Appendix  B  provides  example  horizontal  tracker/smoother  algorithms  that  may  be  used  to 
compute  horizontal  velocity  estimates  from  the  sensor  position  data.  Both  real-time  and  non  real¬ 
time  trackcr/smoother  algorithms  are  described.  Appendix  C  provides  a  vertical  tracker/smoothcr 
that  may  be  used  to  compute  vertical  rate  estimates  from  altitude  inputs  in  100-foot  flight  levels. 
Appendix  D  provides  a  vertical  tracker/smoother  that  may  be  used  to  compute  vertical  rate 


Throughout  this  report.  Mode  S  transponder  register  designators  (Comm-B  Data  Selectors  or  BDS  codes)  are  given 
in  hexadecimal  notation  with  the  subscript  16.  Aircraft  Mode  3/A  identity  codes  are  in  octal  notation  with  the 
subscript  8.  All  other  numeric  values  are  assumed  to  be  in  decimal  notation,  with  no  subscript.  Bit  numbering 
within  a  register  is  with  respect  to  the  start  of  the  56-bit  Comm-B  data  (termed  the  MB  field),  with  the  left-most  bit 
numbered  1 .  Bit  positions  are  expressed  in  decimal. 
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estimates  from  altitude  inputs  in  25-foot  flight  levels  (as  provided  by  some  Mode  S-equipped 
aircraft).  Appendix  E  provides  a  non  real-time  vertical  tracker/smoother  algorithm.  Appendix  F 
describes  how  to  use  values  of  ground  speed  and  other  surveillance  inputs  to  validate  airspeed 
values  for  EHS. 

Appendix  G  describes  the  information  potentially  available  in  the  Mode  S  GICB  routine 
meteorological  register  (44,6).  If  the  aircraft  populates  this  register,  then  the  winds  and 
temperature  data  required  to  fully  validate  the  airspeed  and  heading  data  of  EHS  can  be  extracted 
directly  from  the  aircraft. 

Appendix  H  describes  the  Mode  S  communications  interface  formats  and  protocols 
supporting  the  FAA’s  terminal  sensors.  These  sensors  (specified  in  [6])  do  not  support  the 
ASTERIX  input/output  format  -  rather,  they  provide  data  as  specified  in  [13]  and  [14]. 
Appendix  H  provides  the  techniques  to  use  this  interface  for  ELS/EHS  validation.  Appendix  I 
describes  the  internationally  standardized  ASTERIX  Category  018  interface  used  to  support 
surveillance  and  data  link  communications  functionality  in  sensors  that  do  not  provide  the 
interface  discussed  in  Appendix  H. 

Appendix  J  provides  the  complete  derivation  of  the  equations  used  to  compute  the 
Cartesian  components  of  the  surveillance  radar  measurement  variance  distribution  that  are  given 
in  Section  3.3.  The  Cartesian  components  are  a  function  of  the  radar’s  range,  azimuth,  and 
altitude  position  measurement  variance  (system  parameters)  together  with  the  target  report’s 
range,  azimuth,  and  altitude.  This  appendix  provides  an  example  of  the  application  of  the  master 
equation  in  Section  3.1. 

1.3  Compliance  Verification  Methodology 

The  ELS/EHS  compliance  verification  algorithms  and  procedures  described  in  this  report 
may  be  implemented  as  a  real-time  monitor  or  as  a  post-processing  system  operating  on  recorded 
data  sets.  Lincoln  Laboratory  has  developed  a  post-processing  version  of  the  algorithms  that  is 
currently  being  used  to  validate  compliance  for  aircraft  in  the  coverage  of  two  Mode  S  sensors. 
One  of  these  sensors  is  a  research  asset  operated  by  Lincoln  Laboratory  at  Hanscom  AFB  in 
Lexington,  MA  and  the  other  sensor  is  a  research  asset  operated  by  the  FAA’s  William  J  Hughes 
Technical  Center  in  Atlantic  City,  NJ.  Each  sensor  continuously  detects  the  entry  of  new  Mode  S 
transponders  into  their  airspaces,  enrolls  the  new  transponders,  and  extracts  register  data  using 
standard  Mode  S  protocols  in  the  process  of  surveillance.  Each  sensor  provides  a  flow  of 
correlated  aircraft  surveillance  and  register  data  to  a  dedicated  processor  at  MIT  Lincoln 
Laboratory;  those  processors  record  the  data  (with  time  tags)  in  files  for  each  day;  new  recording 
files  are  initiated  at  midnight  (UTC). 

The  Lincoln  Laboratory  implementation  of  the  ELS/EHS  compliance  verification  data 
analysis  is  performed  in  a  post-processing  mode  on  a  single  file  of  recorded  data,  nominally  once 
a  day.  The  first  processing  step  is  to  build  a  searchable  database  using  the  recorded  data.  The 
analysis  can  be  performed  on  multiple  days  by  processing  multiple  data  files  into  the  database. 
The  data  is  keyed  by  the  aircraft  Mode  S  address  so  that  the  complete  set  of  data  associated  with  a 
specific  aircraft’s  can  be  extracted  for  analysis.  The  transponder’s  datalink  capability,  and  its 
assertions  of  ELS  and  EHS  capability  are  determined  as  the  database  is  built.  In  addition,  the  lists 
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of  transponder  register  availability  are  determined  for  each  aircraft.  (Section  2  describes  the 
analysis  of  transponder  capability  for  ELS  and  EHS.) 

Once  the  database  is  built,  all  data  for  the  most  recent  flight  for  each  aircraft  of  interest  (in 
this  case,  state  aircraft)  are  retrieved  for  further  analysis.  A  smoothed  path  is  computed  based  on 
the  surveillance  reports  for  the  aircraft  and  used  as  the  truth  track  referenced  elsewhere  in  this 
report.  The  smoothed  path  is  used  to  compute  velocity  estimates  (both  horizontal  and  vertical) 
for  use  in  verifying  the  contents  of  the  EHS  registers.  (Appendix  B  of  this  report  describes  the 
horizontal  smoothing  algorithms,  while  Appendices  C  and  D  describe  the  vertical  smoothing 
algorithms.) 

The  next  step  in  the  compliance  determination  process  is  to  step  through  the  ELS/EHS 
register  data  associated  with  the  aircraft  source  data  for  a  given  smoothed  path.  Each  data  item 
containing  aircraft  state  data  is  examined  to  determine  whether  the  reported  data  is  consistent 
(within  some  tolerance)  with  its  corresponding  state  derived  from  the  truth  track;  the  computation 
of  the  tolerances  is  described  in  Section  3,  and  the  data  item  consistency  checks  for  each  ELS  and 
EHS  register  are  described  in  Sections  4  through  9. 

Examination  of  a  register’s  data  items  can  be  conducted  even  in  the  cases  where  the 
capability  and  status  bits  do  not  indicate  availability  of  the  register.  This  is  possible  in  the  case  of 
a  transponder  whose  configuration  and  status  bits  are  not  properly  set,  but  whose  applications  arc 
providing  data  to  the  ELS/EHS  registers.  The  data  tests  described  in  the  following  sections  arc 
processed  if  the  registers  are  available,  even  if  the  status  bits  do  not  indicate  that  availability. 

The  monitoring  system  maintains  counts  of  consistency  checks  and  failures.  Once  all 
individual  data  items  have  been  examined,  the  percentage  of  positive  results  is  computed  and  a 
compliance  determination  is  made  based  on  that  percentage.  Finally,  an  aircraft-specific 
compliance  report  is  produced  based  on  the  results  of  the  tests.  This  process  is  repeated  for  data 
associated  with  each  Mode  S  address  in  the  fleet  of  interest  and  fleet  monitoring  statistics  arc 
produced  based  on  the  collection  of  aircraft-specific  compliance  analyses. 

1.4  Semantics  of  the  Tests 

The  compliance  determination  tests  in  the  following  sections  of  this  report  include  boxes 
containing  colored  text  with  specific  test  information  and  are  arranged  as  follows: 

Test  nn:  The  statement  of  the  test,  with  the  test  number  indicated 

by  “nn.” 

Correct  condition:  Acceptable  results  of  the  test. 

Error  condition:  Test  failure  conditions. 


The  BLUE  text  indicates  which  ELS  or  EHS  element  is  being  tested  and  how  it  is  tested. 
The  GREEN  text  indicates  a  positive  test  result  and  the  RED  text  indicates  the  test  failure. 
“Error  condition:”  indications  in  bold-red  text  are  example  messages  that  could  be  used  in 
non-compliance  reports  to  indicate  the  nature  of  test  failures. 
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The  Error  Conditions  include  text  messages  to  be  generated  by  the  monitoring  system  to 
assist  in  non-compliance  resolution.  An  alert  of  non-compliance  will  contain  one  or  more  of 
these  statements,  one  for  each  detectable  failure.  Whenever  possible,  the  analysis  continues  even 
after  a  test  has  failed.  In  any  event,  a  non-compliance  report  will  indicate  all  detectable  test 
failures. 

It  should  be  noted  that  some  number  of  non-compliance  alerts  might  be  generated  even  for 
an  aircraft  that  is  generally  compliant.  These  alerts  could  be  caused  by  transient  conditions  in  the 
avionics,  irregularities  in  the  surveillance  data,  etc.  The  recorded  data  would  need  further 
analysis  to  determine  the  causes  of  the  alerts  and  whether  they  indicate  anomalies  in  the  testing 
procedures  or  if  they  point  to  actual  system  problems  in  the  aircraft’s  Mode  S  avionics.  One  way 
to  evaluate  overall  compliance  is  to  compute  the  percentage  of  Mode  S  update  scans  that  cause 
alerts  to  be  generated  over  the  length  of  each  aircraft’s  track.  While  the  exact  maximum 
acceptable  alert  percentage  value  for  an  aircraft  to  be  deemed  compliant  remains  to  be 
determined,  it  is  likely  to  be  of  the  order  of  5  percent  or  less. 

1.5  Surveillance  Basics 

Figure  1-3  illustrates  the  layout  of  fields  in  Mode  S  Surveillance  interrogations  and  replies. 
The  standard  surveillance  reply  is  a  56-bit  data  message;  those  replies  do  not  deliver  any  Mode  S 
register  data.  If  the  reply  is  in  response  to  an  altitude  interrogation,  then  downlink  format  (DF) 
number  20  is  used  -  if  the  reply  is  in  response  to  an  identity  interrogation,  then  DF  number  2 1  is 
used.  The  Mode  S  ELS  and  EHS  applications  use  the  1 12-bit  Comm-B  reply  format  to  transfer  a 
56-bit  MB  field  with  the  extracted  contents  of  a  specified  Mode  S  transponder  register  as  part  of 
the  Mode  S  transponder’s  surveillance  response. 

In  either  surveillance  reply  format,  the  left-most  3  bits  of  the  surveillance  & 
communications  control  field  contain  the  flight  status  (FS)  and  the  right-most  13  bits  contain 
either  the  aircraft’s  Mode  C  altitude  or  the  aircraft’s  Mode  3/A  identity  code.  The  middle  1 1  bits 
of  the  surveillance  and  communications  control  field  are  composed  of  a  5-bit  downlink  request 
field  and  a  6-bit  utility  message  field;  those  fields  are  not  significant  to  this  report  and  will  not  be 
further  discussed.  The  address/parity  field  in  each  reply  contains  the  aircraft’s  Mode  S  address 
and  is  used  to  perform  error-detection  and  correction  algorithms  on  the  reply  bits. 


SURVEILLANCE  INTERROGATION  AND  REPLY 


FORMAT 

SURV.  &  COMM. 

ADDRESS/PARITY 

NO. 

CONTROL 

(24  BITS) 

(5  Bits) 

(27  BITS) 

SURVEILLANCE/COMMUNICATION  INTERROGATION  AND  REPLY  -  COMM-A  AND  COMM-B 


FORMAT 

NO. 

(5  Bits) 


SURV.  &  COMM 
CONTROL 
(27  BITS) 


MESSAGE  FIELD 
(56  BITS) 


ADDRESS/PARITY 
(24  BITS) 


112  BITS 


Figure  1-3.  Mode  S  Surveillance/Communications  Data  Formats. 
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If  the  surveillance  source  provides  ASTERIX  Category  048  target  reports  (sec  [5]),  then  the 
56  bits  of  extracted  Mode  S  transponder  register  data  are  provided  in  the  format  of  Data  Item  250, 
illustrated  in  Figure  1-4.  Since  multiple  registers  can  be  extracted  on  a  surveillance  scan,  the  first 
8  bits  of  the  message  contain  a  count  of  the  registers  represented  in  the  ASTERIX  message. 
Following  the  repetition  count  are  one  or  more  MB/BDS  data  blocks.  Each  data  block  contains 
the  56-bit  extracted  Mode  S  transponder  register  contents  (MB  field)  followed  by  the  8-bit  BDS 
code  identifying  the  register. 


Repetition 
count  (8  bits) 

MB  (56  bits) 

BDS 
(8  bits) 

MB  (56  bits) 

L - - - J 

BDS 
(8  bits) 

i _ 

Figure  1-4.  Format  of  ASTERIX  Category  048  Data  Item  250  (Mode  S  MB  Data). 


If  the  Comm  B  data  was  sent  as  a  Mode  S  broadcast  rather  than  a  GICB  extraction,  then  the 
BDS  code  will  be  zero.  The  first  8  bits  of  the  MB  field  for  a  Mode  S  Comm  B  broadcast  message 
contain  the  BDS  code  (e.g.,  registers  10|6,  20|6,  and  30|6).  Mode  S  transponder  registers  20|6  and 
30|6  have  their  own  ASTERIX  formats,  so  they  would  not  be  found  in  an  ASTERIX  Data  Item 
250  message. 


9 


Figure  1-5  illustrates  the  organization  and  basic  data  flows  for  the  subset  of  the  Mode  S 
transponder  registers  used  in  the  ELS  and  EHS  applications.  Color-coding  is  used  to  group  the 
registers  by  application:  ELS  (yellow)  and  EHS  (red).  Registers  shown  in  gray  are  indirectly 
involved  with  these  applications,  but  are  not  directly  called  out  by  the  application  specification. 
The  figure  employs  thick  arrows  to  denote  the  transponder  static  and  dynamic  configuration  data 
flows.  Appendix  A  contains  more  readable  versions  of  the  register  layouts  in  Figure  1-5. 


DF«11 
Of  17 


Mode  S  Reply 
or  Squltter 


LINCOLN  LABORATORY 

Massachusetts  Instttuteof  Technology 


Enhanced  Surveillance  (EHS) 


Dynamic  Configuration 


Register  3016 


ACAS 


Mode  S  Register  Assignments  (Partial) 


Figure  1-5.  Mode  S  Register  Architecture  for  ELS  and  EHS  Data  Link  Applications. 
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2.  CONFIGURATION  VALIDATION 


This  section  discusses  the  status  and  configuration  bits  that  indicate  the  communication  and 
ELS/EHS  capability  of  the  transponder.  The  transponder  must  successfully  pass  all  of  the  tests 
described  below  to  be  deemed  properly  configured  for  ELS  and  EHS  applications.  Further,  the 
transponder  must  pass  each  of  the  data  item  tests  presented  in  Sections  4  though  9  in  order  to  be 
deemed  fully  compliant  with  the  ELS  and  EHS  mandates. 

There  are  a  number  of  bits  and  fields  in  the  Mode  S  transponder  provided  for  avionics 
system  configuration  definition.  Most  of  these  are  static  -  written  once  at  avionics  system 
initialization.  The  ELS/EHS  validation  procedures  described  in  this  report  assume  that  these 
configuration  values  are  examined  once,  in  the  order  listed  in  this  section.  (If  the  configuration  of 
the  avionics  changes  in  flight  (e.g.,  equipment  failures),  then  some  of  the  tests  may  need  to  be 
repeated.)  All  the  tests  in  this  section  must  be  passed  in  order  for  compliance  verification  to 
proceed  with  the  further  validation  tests  in  subsequent  Sections  4  through  9. 

2.1  Capability  (CA)  Field  Validation 

The  3-bit  transponder  capability  (CA)  field  is  obtained  from  either  the  aircraft’s  Mode  S 
All-Call  Reply  and  Acquisition  Squitter  (DF=1 1)  or  the  Extended  Squitter  (DF=17)  downlink 
messages.  The  CA  field  occupies  bits  6  through  8  in  these  messages,  just  after  the  5-bit  downlink 
format  (DF)  field.  To  indicate  support  for  Mode  S  ELS  and  EHS  applications,  the  CA  field  value 
must  be  greater  than  or  equal  to  4. 

The  transponder  capability  should  be  tested  on  acquisition  of  the  aircraft  by  the  surveillance 
sensor: 


Test  01 :  Compare  transponder  CA  field  with  the  value  4. 

Correct  condition:  CA  must  be  greater  than  or  equal  to  4. 

Error  condition:  Transponder  capability  (CA)  value  is  less  than  4;  the 

transponder  does  not  support  Mode  S  data  link  applications. 


Note:  if  the  input  surveillance  source  provides  ASTER1X  Category  048  target 
reports  (see  [5]),  then  the  information  that  would  be  contained  in  the  CA  value  is  available  in  bits 
14  through  16  (the  COM  field)  of  Data  Item  230.  A  value  in  the  COM  field  greater  than  or  equal 
to  1  implies  a  CA  value  greater  than  4. 

2.2  Capability  Register  Validation 

Bits  in  the  Mode  S  Specific-Services  GICB  Capability  registers  of  the  Mode  S  transponder 
indicate  whether  the  aircraft’s  avionics  are  configured  to  support  specific  individual  transponder 
registers.  Register  1  8i6  (see  A-3  for  the  complete  definition  of  the  contents  of  this  register) 
contains  bits  for  the  configuration  status  of  registers  01 16  through  38i6,  which  includes  all  those 
registers  involved  with  ELS.  The  register  configuration  bits  are  assigned  sequentially  starting 
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with  the  low-order  bit  in  the  register  (bit  56).  These  bits  represent  the  wired  configuration  of  the 
avionics  -  they  are  static  and  need  to  be  extracted  only  once  for  any  given  transponder. 

Given  that  the  transponder  CA  field  test  (Section  2. 1)  is  passed,  the  contents  of  register  1 8,6 
should  be  extracted  and  the  tests  in  this  section  performed  once  at  the  acquisition  of  the  aircraft. 
The  register  contents  should  be  extracted  again3  and  these  tests  should  be  repeated  if  the  avionics 
signal  a  change  in  airborne  configuration  via  a  broadcast  of  the  new  settings  for  the  data  link 
capability  register  ( 1 0t6). 

For  a  ModeS  transponder  to  support  ELS,  the  following  bits  in  capability  register  18|6 
must  be  set  to  1 : 

a)  Bit  41  (refers  to  availability  of  register  10|6)  must  be  set  to  1 ; 

Test  02:  Compare  bit  41  of  register  1816  with  the  value  1. 

Correct  condition:  Bit  41  must  equal  1. 

Error  condition:  Bit  41  of  register  1 (Static  Configuration)  is  not  set  to  1, 
_ implying  that  ELS  register  1 0I6  is  not  available. 


b)  Bit  34  (refers  to  availability  of  register  17|6)  must  be  set  to  1; 

Test  03:  Compare  bit  34  of  register  18]6with  the  value  1. 

Correct  condition:  Bit  34  must  equal  1. 

Error  condition:  Bit  34  of  register  1 8]6  (Static  Configuration)  is  not  set  to  1, 
_ implying  that  ELS  register  17|6  is  not  available. 


c)  Bit  25  (refers  to  availability  of  register  20|6)  must  be  set  to  1;  and 

Test  04:  Compare  bit  25  of  register  18]6with  the  value  1. 

Correct  condition:  Bit  25  must  equal  1. 

Error  condition:  Bit  25  of  register  18|6  (Static  Configuration)  is  not  set  to  1, 
implying  that  ELS  register  20)6  is  not  available. 


3  In  a  monitoring  environment  where  data  analysis  is  based  on  recorded  data  from  an  autonomous 
radar,  it  is  not  possible  to  direct  the  radar  to  repeat  a  register  extraction.  In  that  case,  the  analysis 
should  seek  ahead  in  the  data  stream  for  subsequent  extractions;  if  none  are  found,  the  tests 
cannot  be  repeated. 
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d)  If  the  aircraft  is  equipped  with  a  functioning  ACAS  unit  that  is  configured  to 
generate  resolution  advisories  (RAs),  then  bit  9  (refers  to  availability  of  register 
30i6)  must  be  set  to  1.  Bits  16,  38,  and  39  of  the  transponder  Data  Link 
Capability  Report  (register  1 0!6  —  see  Figure  A-l)  indicate  the  ACAS 
configuration  of  the  aircraft’s  avionics.  Bit  39  is  set  to  1  if  the  aircraft  is  ACAS 
equipped.  Bit  16  is  set  to  1  if  the  ACAS  is  currently  operational.  Bit  36  is  set  to 
one  if  the  ACAS  is  generating  RAs  as  well  as  traffic  advisories  (TAs). 


Test  05: 

If  the  aircraft  is  equipped  with  an  operating  ACAS  unit 
capable  of  generating  RAs,  compare  bit  9  of  register  18,6  with 
the  value  1. 

Correct  condition:  Bit  9  must  equal  1. 

Error  condition: 

Bit  9  of  register  181()  (Static  Configuration)  is  not  set  to  1, 
implying  that  ELS  register  30, 6  is  not  available  for  the  output 
of  ACAS  RA  data. 

The  configuration  bits  for  the  EHS  registers  are  found  in  transponder  register  19i6.  (See  A -4 
for  the  complete  definition  of  the  contents  of  this  register).  Given  that  the  transponder  CA  field 
test  (Section  2.1)  is  passed,  the  contents  of  register  19i6  should  be  extracted  and  the  tests  in  this 
section  performed  once  at  the  acquisition  of  the  aircraft.  The  register  contents  should  be 
extracted  again  and  these  tests  should  be  repeated  if  the  avionics  signal  a  change  in  airborne 
configuration  via  a  broadcast  of  the  new  settings  for  the  data  link  capability  register  (10|6). 

For  a  ModeS  transponder  to  support  EHS,  the  following  bits  in  capability  register  19,6 
must  be  set  to  1 : 

a)  Bit  49  (refers  to  availability  of  register  40)6)  must  be  set  to  1 ; 

Test  06:  Compare  bit  49  of  register  19, 6  with  the  value  1. 

Correct  condition:  Bit  49  must  equal  1. 

Error  condition:  Bit  49  of  register  19, 6  (Static  Configuration)  is  not  set  to  1, 
implying  that  EHS  register  40, 6  is  not  available 


b)  Bit  33  (refers  to  register  5016)  must  be  set  to  1;  and 

Test  07:  Compare  bit  33  of  register  1916  with  the  value  1. 

Correct  condition:  Bit  33  must  equal  1. 

Error  condition:  Bit  33  of  register  19, 6  (Static  Configuration)  is  not  set  to  1, 
implying  that  EHS  register  50, 6  is  not  available. 
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c)  Bit  1 7  (refers  to  register  60i6)  must  be  set  to  1 . 


Test  08:  Compare  bit  17  of  register  19|6with  the  value  1. 

Correct  condition:  Bit  17  must  equal  1. 

Error  condition:  Bit  17  of  register  19)6  (Static  Configuration)  not  set  to  1, 
_ implying  that  EHS  register  60|6  is  not  available. 


2.3  Common-Usage  Register  Validation 

The  ModeS  common-usage  transponder  capability  register  (17)6)  contains  configuration 
bits  that  are  set  to  indicate  the  actual  operational  status  (dynamic)  of  the  most  commonly  used 
registers,  including  all  ELS  and  EHS  registers.  (See  A-2  for  the  complete  definition  of  the 
contents  of  this  register).  Given  that  the  appropriate  transponder  configuration  tests  (Sections  2. 1 , 
2.2-b)  are  passed,  the  contents  of  register  18|6  should  be  extracted  and  the  tests  in  this  section 
performed  once  at  the  acquisition  of  the  aircraft.  The  register  contents  should  be  extracted  again 
and  these  tests  should  be  repeated  if  the  avionics  signal  a  change  in  airborne  configuration  via  a 
broadcast  of  the  new  settings  for  the  data  link  capability  register  ( 1 0[6). 

For  a  Mode  S  transponder  to  support  ELS,  bit  7  in  register  17|6  (corresponding  to  register 
20 1 6)  must  be  set  to  1. 


Test  09:  Compare  bit  7  of  register  1 7i6  with  the  value  1. 

Correct  condition:  Bit  7  must  equal  1. 

Error  condition:  Bit  7  of  register  17|6  (Dynamic  Configuration)  is  not  set  to  1, 
implying  that  ELS  register  20l6  is  not  currently  available. 


The  following  additional  configuration  bits  must  be  set  to  1  in  the  common-usage 
capability  register  (17|6)  to  support  EHS: 

a)  Bit  9  (refers  to  register  40|6)  must  be  set  to  1 ; 

Test  10:  Compare  bit  9  of  register  17i6with  the  value  1. 

Correct  condition:  Bit  9  must  equal  1. 

Error  condition:  Bit  9  of  register  17|6  (Dynamic  Configuration)  not  set  to  1, 
implying  that  EHS  register  40|6  is  not  currently  available. 
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b)  Bit  16  (refers  to  register  50i6)  must  be  set  to  1 ;  and 


Test  11:  Compare  bit  16  of  register  17l6  with  the  value  1. 

Correct  condition:  Bit  16  must  equal  1. 

Error  condition:  Bit  16  of  register  17!6  (Dynamic  Configuration)  not  set  to  1, 
implying  that  EHS  register  5016  is  not  currently  available. 


c)  Bit  24  (refers  to  register  60|6)  must  be  set  to  1. 


Test  12: 

Compare  bit  24  of  register  17|6with  the  value  1. 

Correct  condition:  Bit  24  must  equal  1. 

Error  condition: 

Bit  24  of  register  17,6  (Dynamic  Configuration)  not  set  to  1, 
implying  that  EHS  register  60I6  is  not  currently  available. 

2.4  Data  Link  Capability  Register  Validation 

The  Mode  S  transponder  data  link  capability  register  ( 10|6)  contains  a  number  of  avionics 
configuration  and  status  fields.  (See  A-l  for  the  complete  definition  of  the  contents  of  this 
register.)  Given  that  the  appropriate  transponder  configuration  tests  (Sections  2.1,  2.2-a)  arc 
passed,  the  contents  of  register  1 8 i6  should  be  extracted  and  the  tests  in  this  section  performed 
once  at  the  acquisition  of  the  aircraft.  These  tests  should  be  repeated  if  the  avionics  signal  a 
change  in  airborne  configuration  via  a  broadcast  of  the  new  settings  for  the  data  link  capability 
register  (10,6). 

For  a  Mode  S  transponder  to  support  ELS  and  EHS  applications,  the  following  conditions 
must  all  be  true: 

a)  Bits  1  through  8  (BDS  code)  =  10,6; 


Test  13:  Compare  bits  1  through  8  of  register  10I6with  the  value  1 0I6. 

Correct  condition:  Bits  1  through  8  must  equal  10|A. 

Error  condition:  The  value  in  bits  1-8  of  ELS  register  1 0)6  is  not  set  to  10, 6; 
incorrect  register  identifier  (BDS  code). 
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b)  Transponders  built  under  specifications  prior  to  2002  (sub-network  Version  3)  do 
not  support  ELS;  transponders  built  under  specifications  released  in  2002  (sub¬ 
network  Version  3)  or  later  (sub-network  Version  4,  Edition  1  in  2007) 
accommodate  ELS.  Bits  17  through  23  (sub-network  version  number)  of  register 
10|6  must  be  in  the  range  3. ..4; 


Test  14:  Compare  bits  17  through  23  of  register  10i6with  the  values  3 

and  4. 

Correct  condition:  Bits  17  through  23  must  equal 3  or  4. 

Error  condition:  The  value  in  bits  17..23  (sub-network  version  number)  of 

ELS  register  1 0)6  is  not  in  range  3. ..4.  Sub-network  version 
number  is  incorrect. 


c)  Bit  25  (Mode  S-Specific  Services  Capability)  must  be  set  to  1,  indicating  that 
registers  other  than  02|6,  03|6,  04!6,  10|6,  17|6,  lCi6,  20i6,  and  30|6  are  available 
for  down  linking.  A  value  of  zero  in  that  bit  field  means  that  registers  40!6,  50!6, 
and  60|6  are  not  available  for  extraction; 


Test  15:  Compare  bit  25  of  register  1016with  the  value  1. 

Correct  condition:  Bit  25  must  equal  1. 

Error  condition:  Bit  25  of  ELS  register  1 0]f>  (Mode  S  Specific-Services 
Capability)  is  not  set  to  1. 


d)  Bit  33  (Aircraft  Identification  Capability)  must  be  set  to  1  to  indicate  that  the 
aircraft  identification  is  being  provided  to  the  transponder;  and 


Test  16:  Compare  bit  33  of  register  1016with  the  value  1. 

Correct  condition:  Bit  33  must  equal  1. 

Error  condition:  Bit  33  of  ELS  register  10]6  (Aircraft  identification  capability) 
is  not  set  to  1,  indicating  that  the  transponder  cannot  provide 
the  flight  identification. 


e)  Bit  35  (Surveillance  Identifier  Code)  must  be  set  to  1 . 

Test  17:  Compare  bit  35  of  register  10l6  with  the  value  1. 

Correct  condition:  Bit  35  must  equal  1. 

Error  condition:  Bit  35  of  ELS  register  10|fc  (Surveillance  Identifier  Code  (SI) 
capability)  is  not  set  to  1 ,  indicating  that  the  transponder 
does  not  support  SI  codes. 


16 


Note:  if  the  input  surveillance  source  provides  ASTERIX  Category  048  target 
reports  (see  [5]),  then  the  Mode  S-Specific  Services  flag  is  available  as  bit  8  (MSSC  fields)  of 
Data  Item  230.  The  aircraft  identification  capability  flag  is  available  as  bit  6  (AIC  field)  of  Data 
Item  230.  As  indicated  in  text  associated  with  Figure  1-4,  the  contents  of  the  extracted  register 
10|6  are  available  in  Data  Item  250. 
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3.  CALCULATION  OF  VALIDATION  THRESHOLDS 


This  section  provides  the  algorithms  required  to  determine  the  measurement  accuracy 
derivable  from  radar-based  surveillance  data.  When  radar-based  surveillance  data  is  used  to 
validate  Mode  S  EHS  data  values,  these  algorithms  should  be  used  to  determine  the  accuracy 
thresholds  to  be  employed  for  the  validation  comparisons  for  the  respective  data  items.  The 
algorithms  described  in  this  section  calculate  the  data  error  distribution  “sigma”  -  the  standard 
deviation  of  the  value  expected  for  the  particular  variable.  The  validation  thresholds  would 
simply  be  a  multiple  of  the  calculated  sigma  for  the  variable.  A  multiplier  value  of  3  (denoted  V 
throughout  this  section)  is  typically  employed,  since  data  measurement  errors  in  excess  of  three 
standard  deviations  are  rare. 

3.1  Assumptions 

The  equations  used  in  this  section  were  derived  primarily  from  Section  10  of  reference  [4]. 
A  simplifying  assumption  has  been  made  that  the  sources  of  radar  surveillance  data  use  simple 
Kalman  filters  or  tracker  algorithms  (e.g.,  2-point  interpolators  or  alpha-beta  smoothers).  This 
simplifying  assumption  holds  true  for  Mode  S  and  other  current  radar  surveillance  ground 
sensors.  Two  example  horizontal  path  smoothing  algorithms  are  described  in  Appendix  B  of  this 
report,  a  retrospective  (non-real-time)  smoother  appropriate  for  use  in  processing  recorded  data 
for  post-flight  analysis  and  a  real-time  algorithm  appropriate  for  use  in  quick-look  during  flight 
testing. 

The  master  equation  for  the  computation  of  the  various  error  distribution  sigmas  in  this 
report  is  the  following  (10-23  from  [4])  that  defines  how  to  convert  the  measurement  variances 
for  a  function  in  one  coordinate  system  into  corresponding  measurement  variances  for  the 
function  in  another  coordinate  system.  In  the  case  of  this  report,  the  known  variances  are  two- 
dimensional  in  range  and  azimuth  for  the  Mode  S  ground  surveillance  sensor,  but  the  variances  in 
Cartesian  x-y  coordinates  are  desired.  Variance  terms  (sigma  squared)  can  be  directly  added  as 
indicated  in  the  master  equation. 


3.2  Inputs 


The  equations  derived  in  this  section  assume  that  the  sensor  measurement  errors  in  the 
range  and  azimuth  directions  are  inputs  given  as  parameters  of  the  surveillance  radar  sensor  - 
denoted  as  SigmaRange4  and  SigmaAzimuth,  in  nautical  miles,  and  radians,  respectively.  For  a 
typical  US  civilian  Mode  S  sensor,  the  value  of  SigmaRange  is  0.01  nautical  miles  and  the  value 
of  SigmaAzimuth  0.001  radians.  The  values  of  these  surveillance  sensor  parameters  would  be 
configuration  inputs  to  the  validation  testing  software. 


4  See  Section  3.3  for  a  discussion  of  slant  range  and  the  computation  of  ground  range. 
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For  each  surveillance  target  report  correlated  to  a  given  aircraft  track,  the  following  input 
data  items  are  assumed: 

Range:  slant  range  (strict  distance  from  the  sensor),  in  nautical  miles; 

Azimuth:  in  radians  clockwise  from  true  north; 

Altitude:  in  nautical  miles  (or  feet),  typically  barometric;  and 

Time:  time  (also  interchangeably  denoted  T). 

The  aircraft  track  is  assumed  to  maintain  the  previous  values  of  the  report  data,  as  well  as 
previous  values  of  the  data  sigmas  as  calculated  below.  Also,  it  is  assumed  that  the  time 
difference  (or  number  of  scans)  between  the  current  and  previous  correlation  reports  for  the  track 
is  known.  (If  required,  the  number  of  scans  may  be  converted  to  time  units  using  the  system 
scan  time  parameter.) 

If  the  input  surveillance  source  provides  ASTER1X  Category  048  target  reports  (see  [5]), 
then  the  range  and  azimuth  values  are  available  in  Data  Item  040.  Range  is  16  bits  in  units  of 
256ths  of  a  nautical  mile.  Azimuth  is  16  bits  in  units  of  360/65536  degrees  (about  0.0055  degree 
steps).  Time  is  available  in  Data  Item  140  as  a  24-bit  value.  The  time  unit  is  128ths  of  a  second. 
The  correlating  track  number  is  available  in  Data  Item  161  in  the  range  0  to  4095.  Altitude  is 
available  in  Data  Item  090  as  a  14-bit  value  in  units  of  25  feet.  The  upper  two  bits  of  the  16-bit 
altitude  data  item  are  used  to  flag  error  conditions.  The  bits  should  both  be  zero  when  the  altitude 
is  usable. 

3.3  Derived  Intermediate  Terms 

Range  Conversion:  The  Cartesian  ground  position  values  X  and  Y  are  derived  from  the 
measured  range,  azimuth,  and  altitude.  The  first  calculation  is  to  compute  the  ground  range  (the 
distance  from  the  sensor  to  the  spot  on  the  earth  directly  below  the  aircraft)  from  the  slant  (or 
measured)  range  and  altitude.  Since  the  aircraft  for  which  EHS  is  available  will  be  Mode  S- 
equipped,  a  measured  altitude  should  be  available  and  is  used  to  convert  slant  range  to  ground 
range: 


Ground  range  =  (Slant  range2  -  Altitude2)0  5 

If  altitude  is  generally  available,  altitudes  missing  from  some  reports  can  be  substituted  * 

using  an  altitude  smoother  (see  Appendix  C,  D,  or  E).  If  no  altitude  is  available,  use  a  default 
value  of  0.5  nautical  miles  or  !4  of  the  slant  range,  whichever  is  smaller. 

Henceforth  in  this  report  range  refers  to  ground  range  as  computed  above. 

The  horizontal  tracker  algorithms  in  Appendix  B  of  this  report  contain  calculations  of  the 
ground  positions.  Note:  if  the  input  surveillance  source  provides  ASTERIX  Category  048  target 
reports  (see  [5]),  then  the  Cartesian  coordinates  may  be  available  in  optional  Data  Item  042.  Each 
component  value  is  16  bits  long  in  units  of  128ths  of  a  nautical  mile. 
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Coordinate  Conversion:  Derivation  of  the  computations  for  the  measurement  variances  in 
Cartesian  x-y  coordinates  in  this  section  uses  the  master  equation  from  Section  3.1.  Azimuth 
angle  measurement  uses  the  ATC  convention  (clockwise  from  north)  and  the  ground  range. 
Hence: 


X  =  Range  *  sin( Azimuth);  and 
Y  =  Range  *  cos(Azimuth). 

The  measurements  of  range  and  azimuth  are  assumed  to  be  independent,  so  there  are  no 
non-zero  cross-terms  in  range/azimuth.  The  variances  in  the  Cartesian  coordinate  system  are 
dependent  (e.g.,  a  variance  in  azimuth  may  impact  the  variance  in  both  x  and  y),  so  there  is  a 
variance  cross-term  in  x-y. 

This  dependency  in  the  Cartesian  coordinate  variances  is  illustrated  in  the  top-down  view 
of  Figure  3-1.  An  aircraft  is  measured  to  be  at  a  given  range  and  azimuth  from  a  ground  radar 
sensor.  The  shaded  ellipse  illustrates  the  distribution  of  possible  aircraft  positions  (given  standard 
radar  errors  in  range  and/or  azimuth  measurement).  For  example,  consider  a  Mode  S  sensor 
whose  range  error  sigma  is  about  0.01  nautical  miles  (about  60  feet)  and  whose  azimuth  error 
sigma  is  0.001  radians.  At  a  range  of  50  nautical  miles,  the  size  of  the  error  ellipse  in  the  azimuth 
direction  is  about  300  feet.  Note  that  if  the  range  measurement  error  is  positive,  the  error  in  both 
x  and  y  must  be  positive  -  if  the  range  error  is  negative  then  the  error  in  both  x  and  y  must  be 
negative  (the  errors  in  x  and  y  are  dependent).  Similarly,  an  increase  in  the  azimuth  measurement 
implies  an  increase  in  x  and  a  decrease  in  y,  etc. 


Figure  3-1.  Relationship  Between  Ground  Range/Azimuth  and  Cartesian  X-Y  Variances. 
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The  following  equations  are  used  to  calculate  the  values  of  the  squares  of  the  positional 
error  sigma  values  in  units  of  nautical  miles-squared.  (As  was  mentioned  in  Section  3.1, 
variances  (sigma-squared  terms)  are  calculated  so  that  they  can  be  directly  added.)  Denoted 
SigmaX  and  SigmaY,  these  are  the  positional  error  sigma  values  in  Cartesian  coordinates.  There 
is  also  a  cross-term  square  (also  in  units  of  nautical  miles-squared),  SigmaXY2,  that  will  be  used 
in  the  later  calculations  of  SigmaHeading  and  SigmaSpeed.  Only  the  radar  surveillance  range 
and  azimuth  measurement  inputs  are  used  in  these  equations.  (See  Appendix  J  for  the  complete 
derivation  of  these  equations.) 

SigmaX2  =  (SigmaRange2  *sin(  Azimuth)2)  +  (Range2  *  SigmaAzimuth2  *cos(  Azimuth)2) 
SigmaY2  =  (SigmaRange2  *cos( Azimuth)2)  +  (Range2  *  SigmaAzimuth2  *sin(Azimuth)2) 
SigmaXY2  =  [SigmaRange2  -  (Range2  *  SigmaAzimuth2)]  *  sin(Azimuth)  *cos(Azimuth) 

Note:  the  SigmaXY2  term  indicates  the  correlation  between  error  in  the  X-direction  with 
error  in  the  Y-direction.  It  may  be  either  positive  or  negative,  depending  on  the  measured 
azimuth  of  the  aircraft.  The  square  root  of  the  SigmaXY2  term  is  not  required  in  any  further 
calculations,  so  SigmaXY2  being  negative  is  not  a  problem. 

Note:  if  the  input  surveillance  source  provides  ASTERIX  Category  048  target 
reports  (see  [4]),  then  the  Cartesian  X  and  Y  sigma  values  may  be  available  in  optional  Data  Item 
210.  Each  component  is  8  bits  long  in  units  of  128ths  of  a  nautical  mile. 

3.4  Calculating  Heading  Sigma 


The  derivation  of  the  computations  for  the  heading  variance  in  this  section  uses  the  master 
equation  from  Section  3.1.  Heading  is  defined  based  on  the  two  most-recent  measurements  in 
Cartesian  coordinates  as  follows  (this  is  10-31  from  [3]): 


Heading  =  tan 


X  —  X 

current  previous 


\y  current  T previous  J 


employing  ATC  conventions  for  angular  measurement  (i.e.,  clockwise  from  north).  Aircraft 
altitude  is  assumed  to  be  slowly  varying,  so  that  the  impact  of  altitude  changes  on  horizontal 
position  can  be  ignored  in  the  calculations  of  heading  (which  typically  works  on  the  time  scale  of 
one  sensor  scan). 

The  equation  for  SigmaHeading  assumes  that  there  are  values  for  the  current  Cartesian  x-y 
position  as  well  as  the  current  SigmaX,  SigmaY  values,  and  the  cross-term  SigmaXY  value  as 
calculated  in  Section  3.3.  These  values  are  denoted  with  the  subscript  current.  Similarly,  it  is 
assumed  that  there  are  saved  values  for  Cartesian  x-y  position  and  sigma  values  for  the  previous 
measurement  data  point  —  denoted  with  the  subscript  previous.  If  there  is  only  one  data  report 
available  for  a  given  aircraft  track,  then  the  heading  error  sigma  value  for  this  track  cannot  be 
calculated  and  should  default  to  0. 
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The  following  equations  generate  intermediate  terms  for  the  heading  error  sigma 
calculation: 


UeildA  V -^current  "  -^previous,/ 

Delta Y  =  (YCU[ien,  -  ^previous) 

TermX  =  DeltaX2  *  (SigmaY2previous+  SigmaY2current) 

TennY  =  DeltaY2  *  (SigmaX2prcviOUS  +  SigmaX2current) 

TermXY  =  2  *  DeltaX  *  DeltaY  *  (SigmaXY2previous  +  SigmaXY2current) 

Denom  =  (DeltaX2  +  DeltaY2)2 

The  following  equation  yields  the  heading  error  sigma  value  squared  in  units  of  radians- 
squared  based  on  the  intermediate  values  calculated  above.  Note  that  there  must  be  a  protection 
in  the  algorithm  against  a  denominator  value  of  zero  (e.g.,  a  non-moving  aircraft  track).  The 
sigma  heading  error  value  should  be  defaulted  to  infinity  for  this  degenerate  case.  No  heading 
validation  tests  can  be  performed  in  this  default  case. 

SigmaHeading2  =  (TermX  +  TermY  -  TermXY)  /  Denom 

SigmaHeadmg  can  be  prepared  for  use  in  checking  reported  heading  by  taking  the  square  root 
and  converting  to  degrees  (multiplying  by  180/n).  Note:  if  the  input  surveillance  source  provides 
ASTERIX  Category  048  target  reports  (see  [4]),  then  the  heading  sigma  value  may  be  available  in 
optional  Data  Item  210.  The  heading  sigma  value  is  8  bits  long  and  given  in  360/4096  (about 
0.088)  degree  steps. 

3.5  Calculating  Ground  Speed  Sigma 


The  derivation  of  the  computations  for  the  speed  variance  in  this  section  uses  the  master 
equation  from  Section  3.  Speed  is  defined  based  on  the  most-recent  two  measurements  in 
Cartesian  coordinates  as  follows: 


Speed = 

Aircraft  altitude  is  assumed  to  be  slowly  varying,  so  that  the  impact  of  altitude  changes  on 
horizontal  position  can  be  ignored  in  the  calculations  of  speed  (which  typically  work  on  the  time 
scale  of  one  sensor  scan).  The  time  values  are  assumed  to  be  completely  independent  of  the 
position  measurements,  so  only  the  position  variances  come  into  play.  (This  equation  for  speed 
is  a  simplified  version  of  10-34  in  [3],  It  assumes  that  aircraft  maneuvers  (a  non-zero  turn  rate) 
are  taken  into  account  by  a  position  tracker  such  as  that  described  in  Appendix  B  of  this  report.) 

The  calculation  for  SigmaSp€ed  makes  the  same  assumptions  on  inputs  as  the  calculation  for 
SigmaHeading  in  Section  3.4.  The  intermediate  values  DeltaX  and  DeltaY  are  carried  over.  The 
positional  error  sigma  values  are  carried  over  from  Section  3.3.  The  following  equations  derive 


VC 


X current  ^ previous )  CT current  T previous) 


(T'mecurren,-Timepreviou) 
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intermediate  values  for  the  calculation  of  the  square  of  the  sigma  error  for  ground  speed. 
DcltaTime  may  be  computed  directly  (if  report  time  tags  are  available)  or  indirectly  from  the  scan 
count  difference  and  the  radar  sensor’s  scan  period  parameter.  If  there  is  only  one  data  report 
available  for  an  aircraft  track,  then  the  speed  sigma  value  for  the  track  cannot  be  calculated  and 
should  default  to  0. 

DeltaTime  TCUfTent  -  Tprevj0US 

Denom  =  (DeltaX2  +  DeltaY2)  *  DeltaTime2 

TermXCUITent  =  (DeltaX2  *  SigmaX2currenl) 

TermXprevious  —  (DeltaX2  *  SigmaX2previous) 

TermYcurren,  =  (DeltaY2  *  Sigma  Y2currenl) 

TermYprevious  (DeltaY~  SigmaY~prevj0US) 

TermXYculTenl  =  (2  *  DeltaX  *  DeltaY  *  SigmaXY2currcnt) 

TermXYprevious=  (2  *  DeltaX  *  DeltaY  *  SigmaXY2previous) 

Tei  1 1 'current —  Tei'mXcurrent  Y  TermYcun.ent  +  TermXY  current 

TermpreVi0Us  T erniXprevj0US  TermYprevjous  +  TermXYprevj0US 

The  following  equation  gives  the  square  of  the  ground  speed  error  sigma  value  (in  units  of 
nautical  miles  per  time  unit  -  squared).  Note  that  there  must  be  a  protection  against  a 
denominator  value  of  zero  (a  non-moving  track).  Set  the  ground  speed  error  sigma  speed  value  to 
infinity  for  this  case.  No  speed  validation  tests  can  be  performed  in  this  default  case. 

Sigmaspeed'  =  (Term,  urrent  *  Tei  liiprevious) Denom. 

Note:  if  the  input  surveillance  source  provides  ASTERIX  Category  048  target 
reports  (see  [4]),  then  the  speed  sigma  value  may  be  available  in  optional  Data  Item  210.  The 
heading  sigma  value  is  8  bits  long  and  given  in  steps  of  (214)  nautical  miles  per  second  (about 
0.22  knots). 

3.6  Calculating  Heading-Rate  Sigma 

Heading  rate  is  defined  by  the  following  equation  (assuming  no  change  in  turn  rate  over  the 
measurement  time).  The  value  of  heading  from  the  current  measurement  and  the  saved  heading 
from  a  previous  measurement  are  assumed.  If  there  is  only  one  data  report  available  for  an 
aircraft  track,  then  the  heading  rate  sigma  value  for  the  track  cannot  be  calculated  and  should 
default  to  0. 


HeadingRate  =  (Headingcum.nt  -  Headingprevious)  /  DeltaTime 
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‘DeltaTime’  is  the  same  value  used  in  the  calculation  of  ground  speed  in  Section  3.5.  The 
assumption  of  no  turning  acceleration  is  reasonable  for  short  time  periods  and  typical  aircraft 
maneuvers.  (The  horizontal  tracker  algorithm  described  in  Appendix  B  of  this  report  uses  a  turn 
detector  step  to  account  for  aircraft  accelerations.)  The  heading  error  sigma  for  each  heading 
measurement  is  assumed  to  be  available  as  described  in  Section  3.4.  Assuming  that  the  heading 
error  sigma  values  are  independent,  the  square  of  the  error  sigma  for  heading  rate  may  be  given 
simply  as: 


SigmaHeadingRatc2=  2*(SigmaHeadingcurrenl*  SigmaHeadingprevlous)  /  DeltaTime2 

3.7  Calculating  Roll-Angle  Thresholds 

Assuming  that  the  aircraft  is  in  a  level  and  uniform  turn,  the  relationship  between  roll  angle 
'o'  and  the  aircraft's  true  airspeed  ’V’  and  turn  rate  'w'  is  given  by: 


<j)=  tan 


g 


where  'g'  is  the  standard  acceleration  due  to  gravity.  The  aircraft's  turn  rate  'w'  is  obtained  from 
the  validated  track  angle  rate  as  described  in  Section  8.4  (converted  to  radians  per  unit  time).  The 
aircraft’s  true  airspeed  (validation  described  in  Section  8.5)  cannot  be  validated  directly,  since  it 
is  affected  by  local  winds.  The  aircraft’s  ground  speed,  however,  can  be  validated  (as  described 
in  Section  8.3).  Given  that  the  ground  speed  has  been  validated,  the  true  airspeed  data  will  be 
assumed  as  valid  here.  Hence,  given  that  ground  speed,  true  airspeed,  and  track  angle  rate  values 
are  available,  and  the  ground  speed  and  track  angle  rate  have  been  validated,  the  roll  angle  can  be 
validated.  If  the  required  data  fields  are  not  available  or  their  validation  fails,  then  no  further 
validation  of  roll  angle  (other  than  the  basic  “right  turn  equals  right  roll”  test)  can  be  performed. 


The  thresholds  for  passing  the  roll  angle  validation  test  may  be  computed  from  the 
validation  error  sigmas  derived  for  speed  (Section  3.5)  and  heading  rate  (Section  3.6).  Denoting 
the  speed  sigma  Sigmaspeed  and  the  heading  rate  sigma  Sigma  Heading-Rate,  then  the  testing  thresholds 
for  roll  angle  o  are  given  by: 

(V+h*  Sigma  SpccJ  )*(w+n*  Sigma  lh,M/wK  Ralt, ) ' 
g  j 


(b  —  tan  1 

r  max 


=  tan 

t  min 


-1 


(V-»*  SigmaSrt,tJ)*(w-  n  *  Sigma  ,h.MhnK  RaU,) 

g  J 


where  ‘n’  denotes  the  number  of  sigma  data  errors  acceptable  for  validation. 

3.8  Calculating  Altitude  Rate  Thresholds 

Aircraft  may  (depending  on  their  avionics)  report  their  barometrically  derived  altitude  in 
100-foot  quantization  (termed  flight  levels)  or  they  may  report  altitude  in  25-foot  units.  Ground 
sensors  (including  Mode  S)  using  the  Common  Digitizer  (CD-2)  output  format  output  all  aircraft 
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altitudes  in  flight  levels  -  the  altitudes  for  aircraft  reporting  25-foot  increments  are  rounded  to  the 
nearest  flight  level.  Ground  sensors  using  the  ASTERIX  output  format  can  provide  the  25-foot 
data  from  those  aircraft  that  are  capable  of  providing  it. 

Altitude  rate  is  derived  from  the  surveillance  data  using  a  tracker  algorithm.  Appendix  C  of 
this  report  describes  an  algorithm  derived  from  the  Mode  S  Traffic  Information  Service  (T1S) 
application  suitable  for  100-foot  flight  level  data,  while  Appendix  D  describes  an  algorithm 
derived  from  the  ACAS  application  to  be  used  with  25-foot  data.  Appendix  E  describes  a 
non-real-time  vertical  tracker  algorithm  suitable  for  processing  recorded  data. 

The  threshold  for  passing  the  altitude  rate  test  may  be  approximated  by  dividing  the  altitude 
quantization  by  the  time  between  altitude  measurements.  For  100-foot  quantization  and  the 
approximately  5-second  update  period  of  a  Mode  S  terminal  sensor,  this  yields  1200  feet/minute 
as  an  upper  bound  on  altitude  rate  indeterminacy.  (Note:  ACAS  and  TIS  use  the  value  500 
feet/minute  as  the  threshold  for  level  flight.)  For  purposes  of  data  validation,  a  testing  threshold 
of  1000  feet/minute  would  be  appropriate  for  altitudes  quantized  to  100  feet.  If  25-foot  altitude 
data  is  available  (e.g.,  output  from  a  surveillance  sensor  supporting  ASTERIX  output),  a  testing 
threshold  of  250  feet/minute  would  be  appropriate. 
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4.  FLIGHT  STATUS  (FS)  VALIDATION 


The  3-bit  flight  status  (FS)  field  is  contained  in  each  Mode  S  surveillance  reply.  Flight 
Status  includes  three  types  of  information: 

Indication  of  whether  the  aircraft  is  airborne  or  on  the  ground; 

Presence  of  a  Mode  3/A  code  alert  condition;  and 

The  special  position  indicator  (SPI). 

A  Mode  3/A  alert  condition  indicates  that  the  aircraft’s  Mode  3/A  code  has  changed.  There 
are  two  types  of  Mode  3/A  code  alerts:  permanent  and  temporary.  A  permanent  alert  is  a  form  of 
emergency  declaration  -  the  aircraft’s  Mode  3/A  code  has  been  changed  to  7700x,  7600k.  or 
7500x.  Any  other  Mode  3/A  code  change  is  classed  as  a  temporary  alert  indicating  that  the  Mode 
3/A  code  has  been  changed  to  a  non-emergency  value.  The  alert  and  SPI  conditions  arc 
maintained  for  1 8  seconds  after  they  occur. 

The  FS  encoding  is  defined  in  the  following  table. 


Table  4-1 

Surveillance  Status  Codes  and  Definitions 


FS  Code 

Flight  Status  Condition 

0 

Airborne,  No  alert.  No  SPI 

1 

On  the  ground.  No  alert,  No  SPI 

2 

Airborne,  Alert,  No  SPI 

3 

On  the  ground.  Alert,  No  SPI 

4 

Ground  or  Airborne,  Alert,  SPI 

5 

Ground  or  Airborne,  No  Alert,  SPI 

6,7 

Reserved 

The  alert  portion  of  FS  can  be  validated  by  comparison  of  the  Mode  3/A  code  received  from 
sensor  surveillance  against  the  extracted  FS  value.  Note:  if  the  input  surveillance  source  provides 
ASTERIX  Category  048  target  reports  (see  [5]),  then  the  Mode  3/A  code  is  available  in  Data  Item 
070  and  the  FS  value  is  available  in  bits  1 1  through  13  (the  STAT  field)  of  Data  Item  230. 


Test  18:  Check  the  aircraft’s  Mode  3/A  code  for  a  change  in  the  last 

18  seconds.  A  code  change  indicates  an  alert  condition. 

Correct  condition:  If  a  code  change,  then  FS  value  must  be  2,  3,  or  4.  If  no  code 
change,  then  FS  value  must  be  0.  I,  or  5. 

Error  condition:  ELS  Flight  Status  Data  Mode  3/A  alert  invalid:  the  FS  code 
indicates  alert  hut  the  Mode  3/A  code  has  not  changed. 
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Validation  of  the  airbome/on-the-ground  portion  of  FS  may  be  performed  using  a  source  of 
ground  speed  (this  may  be  smoothed/tracked  surveillance  positional  data  such  as  described  in 
Appendix  B)  and  the  aircraft  altitude  data.  Since  the  source  of  altitude  data  from  the  aircraft  is 
barometric  (i.e.,  subject  to  variation  due  to  local  meteorological  conditions)  and  may  have  only 
100-foot  quantization,  it  is  not  possible  to  make  a  fine-grained  determination  of  whether  the 
aircraft  is  on  the  ground  or  not  simply  by  means  of  the  altitude  data.  A  source  of  topographic 
elevation  data  over  the  sensor  coverage  can  be  used  to  refine  the  airbome/on-ground  decision,  but 
it  will  still  not  be  clearly  defined.  Also,  an  aircraft  may  appear  to  be  flying  slowly  because  it  is  in 
a  strong  headwind,  not  because  it  is  taxiing  on  the  ground.  Hence,  there  will  be  cases  where  it  is 
not  possible  to  reliably  differentiate  airborne  from  on  the  ground  with  just  the  available  sensor 
surveillance  data. 

If  the  aircraft’s  ground  speed  is  greater  than  100  knots  or  its  altitude  has  increased  more 
than  200  feet  to  its  current  value,  then  the  aircraft  has  become  airborne.  Note:  if  the  current  speed 
determination  variance  for  the  aircraft  (see  Section  3.5)  is  greater  than  30  knots,  then  the  ground 
speed  test  cannot  be  applied  here. 


Test  19:  Check  the  aircraft’s  ground  speed  and  altitude  change.  If 

the  speed  is  greater  than  100  knots  (with  a  variance  of  less 
than  30  knots)  or  the  altitude  has  increased  more  than  200 
feet  up  to  its  current  value,  then  the  FS  should  indicate 
airborne. 

Correct  condition:  If  the  ground  speed  and  altitude  change  indicate  airborne, 
then  the  FS  value  must  be  0,  2,  4  or  5.  Otherwise,  the  FS 
value  must  be  1,  3, 4,  or  5. 

Error  condition:  ELS  Flight  Status  Data  indicates  on-ground  when  the  state 
data  (ground  speed  and  altitude  change)  indicate  that  the 
aircraft  is  actually  airborne. 
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If  the  aircraft’s  ground  speed  is  less  than  50  knots  and  its  altitude  has  not  increased  by  at 
least  100  feet  to  its  current  value,  then  the  aircraft  is  declared  to  be  on  the  ground.  Note:  if  the 
current  speed  determination  variance  for  the  aircraft  (see  Section  3.5)  is  greater  than  30  knots, 
then  the  ground  speed  test  cannot  be  applied  here. 


Test  20:  Check  the  aircraft’s  ground  speed  and  altitude  change.  If 

the  speed  is  less  than  50  knots  (with  a  variance  of  less  than  30 
knots)  and  the  altitude  has  not  increased  more  than  100  feet 
up  to  its  current  value,  then  the  FS  should  indicate  on  the 
ground. 

Correct  condition:  If  the  ground  speed  and  altitude  change  indicate  on  the 

ground,  then  the  FS  value  must  be  1,  3,  4,  or  5.  Otherwise, 
the  FS  value  must  be  0,  2,  4,  or  5. 

Error  condition:  ELS  Flight  Status  Data  indicates  airborne  when  the  state 
data  (ground  speed  and  altitude  change)  indicate  that  the 
aircraft  is  actually  on  the  ground. 


If  a  topographical  database  of  ground  elevation  with  resolution  of  at  least  one  square  mile 
over  the  sensor’s  coverage  region  is  available,  then  the  actual  height  of  the  aircraft  above  ground 
level  can  be  computed  (subject  to  barometric  variations). 


Test  21:  If  a  source  of  ground  elevation  for  the  aircraft’s  position  is 

known,  compare  the  aircraft’s  reported  altitude  (barometric) 
against  the  ground  elevation.  If  the  altitude  is  more  than  500 
feet  above  the  ground  elevation,  then  the  FS  should  indicate 
airborne. 

Correct  condition:  If  the  ground  elevation  data  and  altitude  indicate  airborne, 
then  the  FS  value  must  be  0,  2,  4,  or  5.  Otherwise,  the  FS 
value  must  be  1,3,  4,  or  5. 

Error  condition:  ELS  Flight  Status  Data  indicates  on-ground  when  the  state 

data  (ground  elevation  and  altitude)  indicate  that  the  aircraft 
is  actually  airborne. 
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Validation  of  the  SPI  bit  portion  of  FS  may  be  performed  by  comparison  directly  against 
the  SPI  value  obtained  through  surveillance.  Note:  if  the  input  surveillance  source  provides 
ASTERIX  Category  048  target  reports  (see  [5]),  then  the  SPI  bit  is  available  in  Data  Item  020  as 
bit  3  of  the  first  byte. 


Test  22:  Check  the  aircraft’s  SPI  code  bit  against  the  FS  value. 

Correct  condition:  If  the  aircraft’s  SPI  bit  is  set,  then  the  FS  value  must  be  4  or 
5.  If  the  SPI  bit  is  not  set,  then  the  FS  value  must  be  0,  1,  2, 
or  3. 

Error  condition:  ELS  Flight  Status  Data  indicates  a  different  SPI  value  from 
that  derived  from  aircraft  state  data. 
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5.  AIRCRAFT  IDENTIFICATION  (REGISTER  20, 6)  VALIDATION 


Mode  S  transponder  register  20,6  supports  the  aircraft  identification  function  for  ELS.  (Sec 
A-5  for  the  complete  definition  of  the  contents  of  this  register.)  Given  that  the  appropriate 
transponder  configuration  tests  (Sections  2.1,  2.2-c,  2.3,  and  2.4)  are  passed,  the  contents  of 
register  20|6  should  be  extracted  and  the  tests  in  this  section  performed  once  at  the  acquisition  of 
the  aircraft.  The  register  should  be  extracted  again  and  these  tests  should  be  repeated  if  the 
avionics  signal  a  change  in  airborne  configuration  via  a  broadcast  of  the  new  settings  for  the  data 
link  capability  register  ( 1 0,6).  If  the  register  data  is  already  available  (e.g.,  in  a  recorded  data 
set),  then  the  tests  in  this  section  should  be  performed  even  if  the  configuration  data  does  not 
indicate  its  support. 

Bits  1  through  8  of  the  register  must  hold  the  BDS  code  value  20|6.  Note:  the  BDS  code  is 
obtained  from  the  sensor  interface  (see  Appendices  G  and  H)  -  it  should  be  duplicated  in  the 
high-order  8  bits  of  the  register  contents.  If  the  input  surveillance  source  provides  ASTERIX 
Category  048  target  reports  (see  [5]),  then  the  6-character  aircraft  identification  data  is  available 
in  the  48  bits  of  Data  Item  240.  This  data  item  employs  the  character  encoding  of  Table  5-1 . 

Test  23:  Compare  bits  1  through  8  of  register  20l6with  the  value  20|6. 

Correct  condition:  Bits  1  through  8  must  equal  20|fc. 

Error  condition:  The  value  in  bits  1-8  of  ELS  register  20|A  is  not  set  to  2(1, 6; 
incorrect  register  identification  (BDS  code) 


The  remaining  48  bits  of  the  register  form  a  string  of  eight  characters.  Character  1  is  in  bits 
9  through  14,  while  character  8  is  in  bits  51  through  56.  The  character  encoding  value  must  obey 
the  following  rules: 


Table  5-1 

Value  Ranges  for  Flight  Identification 


Values 

Character  Type 

1-26 

(letters  A...Z) 

32 

(space) 

48-57 

(digits  0...9) 
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No  other  character  value  (0,  27... 31,  33. ..47,  or  58. ..63)  is  legal  in  the  aircraft  identification 
string  in  register  20  !6. 


Test  24: 

Extract  the  6-bit  character  coding  value  for  each  of  the  8 
characters  in  register  20|6.  Check  each  character  against  the 
valid  entries  in  Table  5-1. 

Correct  condition:  Each  6-bit  character  coding  in  register  20|6  is  valid  (as 

defined  in  Table  5-1). 

Error  condition: 

Invalid  flight  identification  encoding  in  ELS  register  20|h. 
Invalid  character  value(s)  in  the  aircraft  identification  string. 

The  character  string  must  be  left  justified  with  no  intervening  spaces  (encoding  32).  Any 
unused  characters  at  the  end  of  the  string  must  be  set  to  spaces  (encoding  32). 

Test  25:  Extract  the  6-bit  character  coding  value  for  each  of  the  8 

characters  in  register  20)6.  Check  that  any  space 
characters  (coding=32)  are  at  the  end  of  the  character  string 
for  padding. 

Correct  condition:  All  space  characters  (coding=32)  lie  at  the  right  end  of  the 
character  string  for  padding. 

Error  condition:  Invalid  flight  identification  encoding  in  ELS  register  20|6. 

Invalid  use  of  space  characters  in  the  aircraft  identification 
string. 


The  reference  aircraft  identification  data  is  not  obtainable  from  the  sensor  data,  but  can  be 
obtained  from  the  FAA  as  flight  plan  data,  from  the  flight  dispatcher,  or  from  the  pilot  (possibly 
by  voice).  If  the  flight  identification  text  string  is  available  from  an  external  source  (e.g.,  the 
aircraft’s  flight  plan),  then  the  decoded  text  string  from  register  20,6  must  match  it  exactly. 

Test  26:  If  the  aircraft’s  flight  identification  string  is  available  (from 

flight  plan  or  alternate  source),  compare  it  to  the  character 
string  in  register  20]6. 

Correct  condition:  Aircraft  identification  string  from  alternative  input  source 
must  match  string  in  register  20)6  character-for-character. 

Error  condition:  Flight  Identification  data  in  ELS  register  20|6  does  not  match 
flight  identification  in  submitted  flight  plan. 
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6.  ACAS  ADVISORY  (REGISTER  3016)  VALIDATION 


Mode  S  transponder  register  30,6  is  used  to  report  resolution  advisory  (RA)  data  from  an 
onboard  ACAS  unit.  (See  A-6  for  the  definition  of  the  contents  of  this  register.  References  [3] 
and  [9]  provide  additional  details  of  the  coding  used  in  this  register.)  Support  for  this  register  is 
required  if  the  aircraft  is  equipped  with  an  operating  ACAS  unit  that  is  configured  for  RA 
generation.  Bits  16,  38,  and  39  of  the  aircraft’s  Data  Link  Capability  register  ( 1 0]6  -  see  Figure 
A-l)  indicate  the  configuration  of  the  ACAS  unit.  If  any  of  these  bits  are  not  set  to  1,  then  no 
ACAS  advisory  register  validation  should  be  performed.  If  the  register  data  is  already  available 
(e.g.,  in  a  recorded  data  set),  then  the  tests  in  this  section  should  be  performed  even  if  the 
configuration  data  does  not  indicate  its  support. 

The  contents  of  the  ACAS  advisory  register  may  not  be  loaded  by  the  avionics  until  an  RA 
event  occurs.  Until  this  happens,  the  contents  of  the  register  should  remain  cleared  to  all  zero. 
After  the  initial  load  of  register  30)6,  the  BDS  code  value  in  the  first  8  bits  will  be  retained.  For 
ELS  compliance  (once  the  register  has  been  loaded  the  first  time),  bits  1  through  8  (BDS  code) 
must  contain  the  value  30)6.  Note:  the  BDS  code  is  obtained  from  the  sensor  interface  (see 
Appendices  G  and  H)  —  it  should  be  duplicated  in  the  high-order  8  bits  of  the  register  contents. 


Test  27:  If  the  aircraft  indicates  that  an  operational  ACAS  unit 

configured  for  RA  generation  is  onboard  (bits  16, 38,  and  39 
of  Data  Link  Capability  (register  10)6)  all  set  to  1),  then 
compare  bits  1  through  8  of  register  30,6  with  the  value  30l6. 

Correct  condition:  If  all  56  bits  of  register  30k,  are  not  zero  (indicating  that  the 
register  has  been  loaded  at  least  once),  then  bits  I  through  8 
in  register  30l6  must  equal  30u,. 

Error  condition:  The  value  in  bits  1-8  of  ELS  register  30l(1  is  not  set  to  30|4; 
incorrect  register  identifier  (BDS  code). 


Full  testing  of  ACAS  is  beyond  the  scope  of  this  report.  (See  [9]  for  the  complete  test 
procedure  definition  for  ACAS  avionics.)  Further  validation  of  the  contents  of  this  register  is  not 
directly  possible  with  the  surveillance  data  from  a  ground  sensor.  While  it  might  be  possible  to 
use  the  surveillance  tracks  generated  to  drive  a  simulation  of  the  ACAS  algorithms,  the  slower 
update  rates  of  the  ground  surveillance  data  (every  5-12  seconds  as  opposed  to  the  ACAS  I- 
second  update)  would  make  it  difficult  to  ensure  that  the  simulation  was  exact.  Validation  of  the 
operation  of  an  ACAS  unit  would  normally  be  tested  using  a  dedicated  ground  test  unit  capable  of 
generating  appropriate  waveforms  at  1030  and  1090  MHz  to  fully  exercise  the  ACAS  avionics. 

Note:  if  the  input  surveillance  source  provides  ASTERIX  Category  048  target 
reports  (see  [5]),  then  the  ACAS  resolution  advisory  data  is  available  in  the  56  bits  of  Data  Item 
260.  This  resolution  advisory  was  generated  during  the  previous  scan. 
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7.  SELECTED  VERTICAL  INTENTION  (REGISTER  4016)  VALIDATION 


If  the  avionics  configuration  tests  (see  Section  2)  indicate  that  register  40!6  (ModeS 
selected  vertical  intention)  is  supported  by  the  aircraft,  the  contents  of  the  register  should  be 
extracted.  (See  A-7  for  the  definition  and  contents  of  this  register.  References  [2]  and  [3]  provide 
additional  details  of  the  coding  used  in  this  register.)  Since  this  data  changes  infrequently, 
register  40i6  should  be  extracted  at  a  low  sampling  rate  (once  per  major  track  segment,  if  that  can 
be  determined)  and  the  tests  described  in  this  section  should  be  performed  to  validate  the 
extracted  register  contents.  If  the  configuration  data  does  not  indicate  avionics  support  for  the 
Mode  S  selected  vertical  intention  transponder  register  (40!6),  the  register  should  not  be  extracted 
and  the  tests  in  this  section  should  not  be  performed.  If  the  register  data  is  already  available  (e.g., 
in  a  recorded  data  set),  then  the  tests  in  this  section  should  be  performed  even  if  the  configuration 
data  does  not  indicate  its  support. 

The  Mode  S  selected  vertical  intention  transponder  register  (40,6)  contains  five  binary  data 
fields.  Each  data  field  starts  with  a  status  bit  indicating  whether  that  data  field  contains  valid 
information.  At  least  one  of  the  status  bits  (bit  1,  14,  27,  48,  or  54)  must  be  set  in  order  to 
provide  for  EHS  support. 

Test  28:  Examine  status  bits  1,  14,  27, 48,  and  54  in  register  40,,..  At 

least  one  of  the  bits  must  be  non-zero. 

Correct  condition:  At  least  one  of  the  status  bits  1,  14,  27, 48,  or  54  in  register 
40|6  must  be  non-zero. 

Error  condition:  All  data  field  status  bits  in  EHS  register  40)r>  cleared  to  0.  No 
valid  data  in  the  register. 


Bits  40  through  47  and  52  through  53  are  reserved  and  should  be  cleared  to  zero. 

Test  29:  Examine  reserved  bits  40..47  and  52..53  in  register  40lf>.  All 

of  these  bits  must  be  zero. 

Correct  condition:  Bits  40. ..47  and  52...53  in  register  40)ft  must  all  be  zero. 

Error  condition:  Reserved  bits  in  EHS  register  40lfc  are  not  cleared  to  zero; 
invalid  register  contents. 
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If  the  status  bit  for  a  data  field  is  zero  (indicating  that  there  is  no  current  data  for  that  field), 
then  the  data  bits  for  the  field  should  be  cleared  to  all  zeroes. 


Test  30:  Examine  status  bits  1,  14,  27, 48,  and  54  in  register  40)6.  If 

any  status  bit  is  zero,  then  its  corresponding  data  bits  must 
also  be  zero. 

Correct  condition:  (a)  If  bit  1  is  zero,  then  bits  2...13  must  be  zero. 

(b)  If  bit  14  is  zero,  then  bits  15...26  must  be  zero. 

(c)  If  bit  27  is  zero,  then  bits  28. ..39  must  be  zero. 

(d)  If  bit  48  is  zero,  then  bits  49...51  must  be  zero. 

(e)  If  bit  54  is  zero,  then  bits  55...56  must  be  zero. 

Error  condition:  Status  bit(s)  cleared  to  0,  but  corresponding  data  fields  not 
cleared  to  0  in  EHS  register  40t6;  invalid  register  contents. 


Since  the  data  fields  in  this  register  are  functions  of  the  settings  for  the  aircraft’s  FMS 
and/or  MCP,  they  cannot  be  validated  further  from  surveillance  data.  Specific  ground  and  flight 
tests  are  required  (including  the  ability  to  coordinate  between  the  pilot  and  the  test  controller)  to 
exercise  this  register. 

If  the  status  bit  for  MCP/FCU  selected  altitude  (bit  1 )  is  set,  then  the  selected  altitude  in 
feet  (0... 65, 520)  may  be  extracted  as  follows: 

(1)  Extract  bits  2  through  13  as  VAL 

(2)  MCP/FCU  selected  altitude  (feet)  =  16  *  VAL 

The  LSB  of  this  field  is  16  feet.  This  altitude  may  be  derived  from  the  aircraft’s  mode  control 
panel  (MCP),  flight  control  unit  (FCU),  flight  management  system  (FMS),  altitude  alerting 
device,  or  equivalent  pilot  input.  Bits  54  through  56  indicate  the  source  of  the  selected  altitude  in 
the  avionics.  Bit  54  is  the  status  bit  for  the  altitude  source  field.  Bits  55  and  56  encode  the 
altitude  source  as  indicated  in  Table  7-1. 


Table  7-1 


Encoding  of  Target  Altitude  Source  in  Register  40i6 


Encoding  (bits  55,56) 

Description 

00 

Unknown 

01 

Aircraft  altitude 

10 

FCU/MCP  selected  altitude 

11 

FMS  selected  altitude 
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The  data  in  the  MCP/FCU  selected  altitude  field  (and  the  corresponding  altitude  source 
bits)  could  be  validated  by  having  the  pilot  enter  specific  test  values  into  the  appropriate  cockpit 
inputs  on  command  (could  be  done  on  the  ground  or  in  the  air). 

If  the  status  bit  for  FMS  selected  altitude  (bit  14)  is  set,  then  the  selected  altitude  in 
feet  (0. .  .65,520)  may  be  extracted  as  follows: 

( 1 )  Extract  bits  1 5  through  26  as  VAL 

(2)  FMS  selected  altitude  (feet)  =  VAL  *  16 

The  LSB  of  this  field  is  16  feet.  The  data  is  this  field  is  derived  from  the  flight  management 
system  (or  equivalent  input)  managing  the  vertical  profile  of  the  aircraft.  The  data  in  the  FMS 
selected  altitude  could  be  validated  by  having  the  pilot  enter  specific  test  values  into  the 
appropriate  cockpit  inputs  on  command  (could  be  done  on  the  ground  or  in  the  air). 

If  the  status  bit  for  barometric  pressure  setting  (bit  27)  is  set,  then  the  pressure  setting  in 
millibars  may  be  extracted  as  follows: 

( 1 )  Extract  bits  28  through  39  as  VAL 

(2)  Barometric  pressure  setting  (millibars)  =  (VAL  /  10)  +  800 

The  LSB  for  the  barometric  pressure  setting  is  0. 1  millibars.  If  the  actual  setting  is  less  than  800 
mb  or  greater  than  1209.5  mb,  then  the  status  bit  for  this  field  should  be  zero  to  indicate  invalid 
data  and  the  data  field  should  be  cleared  to  zero.  The  data  in  the  barometric  pressure  setting 
could  be  validated  by  having  the  pilot  enter  specific  test  values  into  the  appropriate  cockpit  inputs 
on  command  (this  could  be  done  on  the  ground  or  in  the  air). 

If  the  status  bit  for  the  MCP/FCU  mode  bit  field  (bit  48)  is  set,  then  bits  49  through  51 
indicate  the  current  setting  of  particular  altitude  modes  in  the  aircraft.  If  a  particular  bit  is  set,  this 
indicates  that  the  mode  is  currently  active.  Bit  49  indicates  the  vertical  navigation  mode,  bit  50 
indicates  the  altitude-hold  mode,  and  bit  5 1  indicates  the  approach  mode.  The  data  in  these  bits 
could  be  validated  by  having  the  pilot  enter  specific  test  values  into  the  appropriate  cockpit  inputs 
on  command  (could  be  done  on  the  ground  or  in  the  air). 

Note:  if  the  input  surveillance  source  provides  ASTERIX  Category  048  target  reports  (sec 
[5]),  then  the  contents  of  the  extracted  register  40|6  are  available  in  Data  Item  250  as  described  in 
Figure  1-2. 
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8.  TRACK  AND  TURN  (REGISTER  50, 6)  VALIDATION 


If  the  avionics  configuration  tests  (see  Section  2)  indicate  that  register  50|6  (Mode  S  track 
and  turn  report)  is  supported  by  the  aircraft,  the  contents  of  the  register  should  be  extracted  on 
each  scan  of  the  surveillance  sensor  and  the  tests  in  this  section  should  be  performed  to  validate 
the  extracted  register  contents.  The  register  should  not  be  extracted  and  the  tests  in  this  section 
should  not  be  performed  if  the  configuration  data  does  not  indicate  support  for  the  Mode  S  track 
and  turn  transponder  register  (50i6).  If  the  register  data  is  already  available  (e.g.,  in  a  recorded 
data  set),  then  the  tests  in  this  section  should  be  performed  even  if  the  configuration  data  does  not 
indicate  its  support. 

As  noted  in  Section  1 .3,  an  error  condition  for  the  contents  of  this  register  may  be  observed 
occasionally  due  to  anomalous  surveillance  tracking  or  other  causes.  The  percentage  of  register 
50|6  extractions  that  generate  error  alerts  should  be  computed  for  each  aircraft  track.  While  the 
appropriate  threshold  value  for  this  percentage  to  indicate  EHS  non-compliance  is  yet  to  be 
determined,  it  is  likely  to  be  less  than  5  percent. 

The  Mode  S  track  and  turn  transponder  register  (50,6)  contains  five  binary  data  fields. 
(See  A-8  for  the  complete  definition  of  the  contents  of  this  register.)  Each  data  field  starts  with  a 
status  bit  indicating  whether  that  data  field  contains  valid  information.  At  least  one  of  the  status 
bits  (bit  1 ,  12,  24,  35,  or  46)  must  be  set  to  1  in  order  to  provide  for  EHS  support. 

Test  31:  Examine  status  bits  1,  12,  24, 35,  and  46  in  register  50l6.  At 

least  one  of  the  bits  must  be  non-zero. 

Correct  condition:  At  least  one  of  the  status  bits  1,  12,  24,  35,  or  46  in  register 
50)6  must  be  non-zero. 

Error  condition:  All  data  field  status  bits  in  EHS  register  50|h  cleared  to  0.  No 
valid  data  in  the  register. 
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If  the  status  bit  for  a  particular  data  field  is  zero  (indicating  that  there  is  no  current  data  for 
that  field),  then  the  data  bits  for  the  field  should  be  cleared  to  all  zeroes. 


Test  32:  Examine  status  bits  1,  12,  24, 35,  and  46  in  register  50!6.  If 

any  status  bit  is  zero,  then  its  corresponding  data  bits  must 
also  be  zero. 

Correct  condition:  (a)  If  bit  1  is  zero,  then  bits  2...1 1  must  be  zero. 

(b)  If  bit  12  is  zero,  then  bits  13...23  must  be  zero. 

(c)  If  bit  24  is  zero,  then  bits  25. ..34  must  be  zero. 

(d)  If  bit  35  is  zero,  then  bits  36...45  must  be  zero. 

(e)  If  bit  46  is  zero,  then  bits  47...56  must  be  zero. 

Error  condition:  Status  bit(s)  cleared  to  0,  but  corresponding  data  fields  not 
cleared  to  0  in  EHS  register  50i6;  invalid  register  contents. 


Note:  if  the  input  surveillance  source  provides  ASTERIX  Category  048  target  reports  (see 
[5]),  then  the  contents  of  the  extracted  register  50)6  are  available  in  Data  Item  250  as  described  in 
Figure  1-2. 

8.1  Roll  Angle 

If  status  bit  1  is  cleared  to  zero  (indicating  that  no  roll  angle  data  is  available),  then  bits  2 
through  1 1  must  be  cleared  to  zero.  (This  is  covered  in  test  32(a)  of  section  8.0.)  If  status  bit  1  is 
set,  then  the  signed  roll  angle  value  in  degrees  is  extracted  from  register  50,6  as  follows: 

( 1 )  Extract  bit  2  as  SIGN 

(2)  Extract  bits  3  through  1 1  as  VAL 

(3)  If  SIGN=1,  then  VAL  =  VAL  -  29 

(4)  Roll  Angle  (degrees)  =  (VAL  *  90)  /  29 

Roll  angle  has  the  range  of  values  -90,..., 90  degrees  measured  with  respect  to  horizontal  (wings 
level).  By  convention,  negative  roll  angles  indicate  counterclockwise  (left  wing  down). 

As  was  described  in  Section  3.7,  the  aircraft’s  roll  angle  in  normal  flight  is  a  function  of  the 
true  airspeed  and  turn  rate.  The  relationship  between  roll  angle  'o'  and  the  aircraft’s  true  airspeed 
‘V’  and  turn  rate  ’w’  is  given  by: 


o  =  tan'1  {(V  *  w)  /  g} 

where  ’g’  is  the  standard  acceleration  due  to  gravity  (32  feet/second2).  The  aircraft's  turn  rate  W 
is  obtained  from  the  validated  track  angle  rate  (converted  to  radians  per  second)  as  described  in 
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Section  8.4.  The  aircraft’s  ‘V’  value  is  obtained  from  the  validated  true  airspeed  (converted  to 
units  of  feet/second)  as  described  in  Section  8.5. 

The  extracted  roll  angle  value  is  validated  by  comparing  the  computed  roll  angle  'o’  to  the 
extracted  roll  angle.  The  threshold  values  for  this  comparison  are  defined  in  Section  3.7.  If  the 
airspeed  value  is  not  available  (or  not  validated),  then  only  a  crude  test  can  be  performed  using 
the  track  angle  rate  obtained  from  surveillance  tracking  (or  the  extracted  value  if  validated). 
Basically,  this  is  a  right  turn  equals  right  bank  sort  of  test.  The  sign  of  the  roll  angle  should  be 
the  same  as  the  sign  of  the  track  angle  rate. 


Test  33:  Compare  the  Roll  Angle  value  in  register  50!6  with  the 

surveillance-derived  roll  angle  for  the  aircraft  (computed 
from  turn  rate  and  true  airspeed).  The  test  is  not  performed 
if  either  the  turn  rate  (Section  8.4)  or  the  true 
airspeed  (Section  8.5)  has  not  been  validated  from  the 
current  contents  of  register  50i6. 

If  either  validated  turn  rate  or  air  speed  is  not  available,  then 
a  crude  roll  angle  test  is  performed  using  only  the 
surveillance-derived  track  angle  rate. 

Correct  condition:  If  the  aircraft’s  track  angle  rate  and  it’s  true  airspeed  have 
already  been  validated,  then  the  magnitude  of  the  difference 
between  the  Roll  Angle  value  in  register  50I6  and  the 
surveillance-derived  roll  angle  for  the  aircraft  must  be  less 
than  the  roll  angle  threshold  as  defined  in  Section  3.7. 

If  either  the  validated  turn  rate  or  true  air  speed  is  not 
available  from  register  50i6,  then  the  sign  of  the  Roll  Angle 
value  must  equal  the  sign  of  the  track  angle  rate. 

Error  condition:  Roll  Angle  field  in  EHS  register  50i6  is  inconsistent  with 

aircraft  state  data  derived  from  independent  ground-based 
surveillance. 


8.2  True  Track  Angle 

If  status  bit  12  is  cleared  to  zero  (indicating  that  no  true  track  angle  data  is  available),  then 
bits  1 3  through  23  must  be  cleared  to  zero.  (This  is  covered  in  test  32(b)  of  Section  8.0.)  If  status 
bit  12  is  set,  then  the  signed  true  track  angle  value  in  degrees  is  extracted  from  register  50j6  as 
follows: 

(1)  Extract  bit  13  as  SIGN 

(2)  Extract  bits  14  through  23  as  VAL 

(3)  IfSIGN=l,  then  VAL  =  VAL- 210 
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(4)  True  Track  Angle  (degrees)  =  (VAL  *  180)  /  2 10 

Track  angle  has  the  range  of  values  -180, ...,180  degrees  measured  with  respect  to  true  north.  By 
convention,  negative  angles  indicate  counterclockwise  (west). 

Validation  of  the  true  track  angle  value  is  performed  through  the  comparison  of  the 
extracted  true  track  angle  value  to  the  true  track  angle  value  computed  using  surveillance  position 
reports  and  a  tracker  such  as  the  one  described  in  Appendix  B  of  this  report.  The  true  track  angle 
for  a  given  aircraft  track  would  be  computed  from  the  aircraft’s  Cartesian  velocity  components 
as: 


Track  Angle  =  ATCatan2(  TRACK.XDE,  TRACK. YDE  ) 

It  must  be  noted  that  the  angular  conventions  of  ATC  are  different  from  those  of 
mathematics.  ATC  applications  measures  angles  clockwise  from  north,  while  mathematics 
measures  angles  counterclockwise  from  the  positive  x-axis  (east).  Hence,  the  atan2()  function  of 
standard  computing  languages  must  be  modified  for  this  application.  The  function 
ATCatan2  (XD,YD  )  is  defined  here  as: 

IF  (YD  =  0)  THEN 

Special  case  for  on  x-axis 

IF  (XD  •  0)  return  90 

ELSE  return  -90 

IF  (XD  =  0)  THEN 

Special  case  for  on  y-axis 

IF  (YD  •  0)  return  0 

ELSE  return  180 

angle  =  atan(  XD  /  YD  ) 

angle  =  angle  *  360  /  (2  *  pi)  convert  from  radians  to  degrees 

IF  (YD  •  0)  THEN 

IF  (XD  <  0)  THEN 

angle  =  angle  +  360 

ELSE 

angle  =  angle  +  180 

IF  (angle  >  180)  THEN 

angle  =  angle  -  360  convert  to  range  -180.. 180 

Note  that  the  tracker  described  in  Appendix  B  of  this  report  requires  three  updates  on  a 
track  before  a  valid  track  angle  estimate  can  be  made.  No  track  angle  validation  should  be 
performed  until  the  fourth  update  of  the  track. 

Another  complication  is  that  some  Mode  S  surveillance  sensors  are  calibrated  with  respect 
to  magnetic  north  rather  than  geographic  north.  (In  the  U.S.,  terminal  Mode  S  sensors  use 
magnetic  north  as  their  reference.)  For  these  sensors,  the  computed  track  angle  will  need  to  be 


42 


corrected  for  the  magnetic  deviation  at  the  sensor  (a  calibration  parameter).  Care  must  be  taken 
to  use  up-to-date  calibration  values,  as  the  magnetic  declination  (difference  between  magnetic 
and  true  north)  can  vary  by  as  much  as  2  to  25  degrees  per  century  depending  on  the  latitude  of 
the  sensor.  By  convention,  a  positive  magnetic  declination  indicates  that  magnetic  north  is  east  of 
true  north  (a  clockwise  rotation  of  the  axes).  Figure  8-1  (from  [12])  illustrates  the  magnetic 
deviations  for  the  continental  United  States.  The  magnetic  deviation  value  in  the  continental  U.S. 
ranges  from  about  -20  degrees  in  Maine  to  almost  +20  degrees  in  Washington  State. 

Figure  8-1:  Magnetic  Declination  for  the  U.S.  (2004). 
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Note:  if  the  input  surveillance  source  provides  ASTERIX  Category  048  target 
reports  (see  [5]),  then  the  true  track  angle  can  be  obtained  from  the  second  16  bits  of  Data  Item 
200.  The  track  angle  is  given  in  units  of  degrees  (0. .  .360)  with  an  LSB  of  360*2'16  (about  0.0055 
degrees).  The  ASTERIX  specification  does  not  define  how  the  sensor  is  to  compute  track 
angle  (i.e.,  what  sort  of  tracker  is  to  be  used),  so  care  must  be  taken  to  ensure  that  sufficient 
smoothing  is  being  performed. 
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The  thresholds  to  use  for  comparison  of  the  extracted  true  track  angle  and  the  computed 
true  track  angle  are  to  be  calculated  as  shown  in  Section  3.4.  These  thresholds  will  vary  as  a 
function  of  aircraft  position  and  its  direction  of  flight  relative  to  the  Mode  S  surveillance  sensor. 

Test  34:  Compare  the  True  Track  Angle  value  in  register  50|6  with 

the  surveillance-derived  track  angle  for  the  aircraft 
corrected  to  geographic  north  (if  required).  The  test  is  not 
performed  if  the  surveillance  track  is  not  yet  fully  mature. 

Correct  condition:  The  magnitude  of  the  difference  between  the  True  Track 
Angle  value  in  register  50|fe  and  the  surveillance-derived 
track  angle  for  the  aircraft  (referenced  to  geographic  north) 
must  be  less  than  the  heading  sigma  threshold  as  defined  in 
Section  3.4. 

Error  condition:  True  Track  Angle  field  in  EHS  register  50)6  is  inconsistent 
with  aircraft  state  data  derived  from  independent  ground- 
based  surveillance. 


8.3  Ground  Speed 

If  status  bit  24  is  cleared  to  zero  (indicating  that  no  ground  speed  data  is  available),  then 
bits  25  through  34  must  be  cleared  to  zero.  (This  is  covered  in  test  32(c)  of  Section  8.0.)  If  status 
bit  24  is  set,  then  the  ground  speed  value  in  knots  is  extracted  from  register  50!6  as  follows: 

(1)  Extract  10  bits  25  through  34  as  VAL 

(2)  Ground  Speed  (knots)  =  VAL  *  2 

The  LSB  for  ground  speed  values  is  2  knots.  If  the  actual  ground  speed  of  the  aircraft  exceeds 
2046  knots,  then  the  ground  speed  value  reported  in  the  register  will  be  limited  to  a  maximum  of 
2046  knots. 

The  ground  speed  value  is  validated  by  comparing  the  extracted  ground  speed  value  to  the 
ground  speed  value  computed  using  surveillance  position  reports  and  a  tracker  such  as  the  one 
described  in  Appendix  B.  The  ground  speed  for  a  given  aircraft  track  would  be  computed  from 
its  Cartesian  velocity  components  as: 

Ground  Speed  =  (  TRACK.XDE2  +  TRACK. YDE2 )° 5 

The  tracker  algorithm  described  in  Appendix  B  computes  the  ground  speed  internally  as 
TRACK.speed.  This  value  could  be  used  directly  for  validation. 

Note  that  the  tracker  described  in  Appendix  B  requires  three  updates  on  a  track  before  a 
valid  speed  estimate  can  be  made.  No  ground  speed  validation  should  be  performed  until  the 
fourth  update  of  the  track. 
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Note:  if  the  input  surveillance  source  provides  ASTERIX  Category  048  target 
reports  (see  [5]),  then  the  ground  speed  can  be  obtained  from  the  first  16  bits  of  Data  Item  200. 
The  ground  speed  is  given  in  units  of  nautical  miles  per  second  and  the  LSB  is  2' 14  nautical 
miles/second  -  about  0.22  knots.  The  ASTERIX  specification  does  not  define  how  the  sensor  is 
to  compute  ground  speed  (i.e.,  what  sort  of  tracker  is  to  be  used),  so  care  must  be  taken  to  ensure 
that  sufficient  smoothing  is  being  performed. 

The  thresholds  to  use  for  comparison  of  the  extracted  ground  speed  and  the  computed 
ground  speed  are  to  be  calculated  as  shown  in  Section  3.5.  These  thresholds  will  vary  as  a 
function  of  aircraft  position  and  its  direction  of  flight  relative  to  the  Mode  S  surveillance  sensor. 

Test  35:  Compare  the  Ground  Speed  value  in  register  50i6  with  the 

surveillance-derived  track  speed  for  the  aircraft.  The  test  is 
not  performed  if  the  surveillance  track  is  not  yet  fully 
mature. 

Correct  condition:  The  magnitude  of  the  difference  between  the  Ground  Speed 
value  in  register  50i6  and  the  surveillance-derived  speed  for 
the  aircraft  must  be  less  than  the  speed  sigma  threshold  as 
defined  in  Section  3.5. 

Error  condition:  Ground  Speed  field  in  EHS  register  50i6  is  inconsistent  with 
aircraft  state  data  derived  from  independent  ground-based 
surveillance. 


8.4  Track  Angle  Rate 

If  status  bit  35  is  cleared  to  zero  (indicating  that  no  track  angle  rate  data  is  available),  then 
bits  36  through  45  must  be  cleared  to  zero.  (This  is  covered  in  test  32(d)  of  Section  8.0.)  If  status 
bit  35  is  set,  then  the  signed  track  angle  rate  value  in  units  of  degrees  per  second  is  extracted  from 
register  50i6  as  follows: 

( 1 )  Extract  bit  36  as  SIGN 

(2)  Extract  bits  37  through  45  as  VAL 

(3)  If  SIGN=1,  then  VAL  =  VAL  -  29 

(4)  Track  Angle  Rate  (degrees/second)  =  (VAL  *  16)  /  29 

Track  angle  rate  has  the  range  of  values  -16...  16  degrees/second.  By  convention,  negative  values 
indicate  counterclockwise  (left).  The  LSB  for  track  angle  rate  values  is  l/32nd  of  a  degree  per 
second.  If  the  magnitude  of  the  aircraft’s  track  angle  rate  exceeds  16  degrees/second,  then  it  will 
be  reported  as  16  degrees/second  with  the  appropriate  sign.  For  example,  a  standard-rate  turn  in  a 
civilian  aircraft  is  about  3  degrees/second. 
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Track  angle  rate  is  validated  by  comparing  its  value  to  the  rate  of  change  of  the  surveillance 
track’s  heading  as  described  in  Section  8.2.  The  track  angle  rate  at  any  surveillance  update  is 
given  by: 

Track  Angle  Rate  (Track  Angle  current  Track  Angle  previous)  /  (Time  cunent  Time  previous) 

The  track  angle  rate  tracker  maintains  a  previous  update’s  value  of  track  angle.  Hence, 
track  angle  rate  validation  cannot  be  done  until  one  update  after  track  angle  can  be  obtained  from 
the  surveillance  tracker.  A  simple  smoothing  algorithm  might  be  used  here  to  reduce  fluctuations 
in  the  rate  value  due  to  measurement  noise.  The  threshold  to  use  for  validating  the  track  angle 
rate  value  is  defined  in  Section  3.6. 


Test  36:  Compare  the  Track  Rate  value  in  register  50|6  with  the 

surveillance-derived  heading  rate  for  the  aircraft.  The  test  is 
not  performed  if  the  surveillance  track  is  not  yet  fully 
mature. 

Correct  condition:  The  magnitude  of  the  difference  between  the  Track  Angle 
value  in  register  50|6  and  the  surveillance-derived  heading 
rate  for  the  aircraft  must  be  less  than  the  heading  rate  sigma 
threshold  as  defined  in  Section  3.6. 

Error  condition:  Track  Angle  Rate  field  in  EHS  register  50, 6  is  inconsistent 
with  aircraft  state  data  derived  from  independent  ground- 
based  surveillance. 


8.5  True  Airspeed  (TAS) 

If  status  bit  46  is  cleared  to  zero  (indicating  that  no  ground  speed  data  is  available),  then 
bits  47  through  56  must  be  cleared  to  zero.  (This  is  covered  in  test  32(e)  of  Section  8.0.)  If  status 
bit  46  is  set,  then  the  true  airspeed  value  in  knots  is  extracted  from  register  50,6  as  follows: 

(1)  Extract  10  bits  47  through  56  as  VAL 

(2)  True  Airspeed  (knots)  =  VAL  *  2 

The  LSB  for  true  airspeed  values  is  2  knots.  If  the  actual  true  airspeed  of  the  aircraft  exceeds 
2046  knots,  then  the  true  airspeed  value  reported  in  the  register  will  be  limited  to  2046  knots. 

As  is  described  in  Appendix  F  of  this  report,  the  true  airspeed  value  is  a  function  of  the 
local  winds  at  the  aircraft’s  location,  the  aircraft’s  barometric  altitude,  and  the  air  temperature  at 
the  aircraft’s  location.  The  ground  Mode  S  sensor  has  available  the  aircraft’s  barometric  altitude 
data  from  surveillance.  The  air  temperature  can  be  approximated  for  a  standard  day  using  the 
equation  given  in  Appendix  F.  However,  there  is  no  direct  way  for  the  ground  Mode  S  sensor  to 
determine  the  local  winds.  Hence,  there  is  no  way  to  directly  validate  the  true  airspeed  value  with 
surveillance  data.  However,  since  an  aircraft  whose  avionics  are  supporting  EHS  also  provides 
values  of  indicated  airspeed  (Section  9.2)  and  Mach  (Section  9.3)  in  register  60|6,  it  is  possible  to 
employ  the  techniques  from  Appendix  F  of  this  report  to  check  the  three  airspeed  values  for 
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consistency.  Given  a  known  altitude  and  any  two  airspeed  values,  it  is  possible  to  derive  the  air 
temperature.  (Alternatively,  just  use  the  standard  day  temperature  value.)  With  all  three  airspeed 
values,  a  crosscheck  that  each  pair  yields  the  same  temperature  (and  that  it  is  in  reasonable 
agreement  with  the  standard  day  value)  may  be  used  to  validate  the  true  airspeed  value.  The 
speed  variation  threshold  value  to  be  used  is  defined  in  Section  3.5. 

A  full  validation  of  the  true  airspeed  value  is  possible  if  the  particular  aircraft  populates  the 
routine  meteorological  register  44,6  (see  Appendix  G).  This  register  provides  the  values  of  wind 
speed/direction  and  air  temperature  measured  on  the  aircraft  itself.  Alternatively,  the  true 
airspeed  value  would  be  validated  through  a  coordinated  test  procedure  where  the  aircraft  would 
fly  at  known  airspeeds. 

If  a  large  population  of  ELS/EHS-equipped  aircraft  is  in  the  coverage  of  the  Mode  S 
ground  sensor,  it  may  be  possible  to  build  up  a  database  of  wind  vector  data  by  computing  the 
offsets  between  ground  speed/true  track  angle  and  airspeed/magnetic  heading.  This  estimate  of 
the  current  winds  (a  function  of  position  and  altitude)  could  be  used  to  convert  the  surveillance- 
validated  aircraft  information  (ground  speed  and  true  track  angle)  into  measures  of  aircraft- 
derived  data. 


Test  37: 

Compare  the  True  Airspeed  (TAS)  value  in  register  50i6  with 
the  surveillance-derived  ground  speed  for  the  aircraft.  The 
test  is  not  performed  if  the  surveillance  track  is  not  yet  fully 
mature.  The  effect  of  local  winds  and  air  temperature  on  the 
aircraft’s  TAS  must  be  accounted  for.  This  may  be  done  via 
extraction  of  the  aircraft-measured  wind  and  temperature 
data  (see  Appendix  G  of  this  report),  having  the  aircraft  fly  a 
known  TAS,  or  other  means. 

Lacking  the  wind  correction  data,  the  test  would  involve 
comparing  the  three  measures  of  airspeed  provided  by 

EHS  (TAS  in  register  50i6,  IAS  and  Mach  in  register  60i6)  for 
consistency  via  the  techniques  in  Appendix  F. 

Correct  condition:  The  magnitude  of  the  difference  between  the  True 

Airspeed  (TAS)  value  in  register  5016  and  the  surveillance- 
derived  speed  for  the  aircraft  (corrected  for  the  local  winds 
and  air  temperature  at  the  aircraft)  must  be  less  than  the 
speed  threshold  as  defined  in  Section  3.5.  If  the  local  w  ind 
and  temperature  data  is  not  available  (or  correctable),  then 
this  test  cannot  be  performed. 

Lacking  the  wind  correction,  check  that  TAS  is  consistent 
with  the  values  of  IAS  and  Mach  in  register  60i6  (if  available) 
within  the  speed  threshold  as  defined  in  Section  3.5. 

Error  condition: 

True  Airspeed  field  in  EHS  register  50w,  is  inconsistent  with 
other  measures  of  airspeed. 
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9.  HEADING  AND  SPEED  (REGISTER  6016)  VALIDATION 


If  the  avionics  configuration  tests  (see  Section  2)  indicate  that  register  60j6  (Mode  S 
heading  and  speed  report)  is  supported  by  the  aircraft,  the  contents  of  the  register  should  be 
extracted  on  each  scan  of  the  surveillance  sensor  and  the  tests  in  this  section  should  be  performed 
to  validate  the  extracted  register  contents.  The  register  should  not  be  extracted  and  the  tests  in 
this  section  should  not  be  performed  if  the  configuration  data  does  not  indicate  support  for  the 
Mode  S  heading  and  speed  transponder  register  (60i6).  If  the  register  data  is  already  available 
(e.g.,  in  a  recorded  data  set),  then  the  tests  in  this  section  should  be  performed  even  if  the 
configuration  data  does  not  indicate  its  support. 

As  noted  in  Section  1.3,  an  error  condition  for  the  contents  of  this  register  may  be  observed 
occasionally  due  to  anomalous  surveillance  tracking  or  other  causes.  The  percentage  of  register 
60i6  extractions  that  generate  error  alerts  should  be  computed  for  each  aircraft  track.  While  the 
exact  threshold  value  for  this  percentage  to  indicate  EHS  non-compliance  is  not  yet  determined,  it 
is  likely  to  be  less  than  5  percent. 

The  Mode  S  heading  and  speed  transponder  register  (60]6)  contains  five  binary  data  fields. 
See  A-9  for  the  complete  definition  of  the  contents  of  this  register.  Each  field  starts  with  a  status 
bit  indicating  whether  that  data  field  is  valid.  At  least  one  of  the  status  bits  (bit  1,13,  24,  35,  or 
46)  must  be  set  to  1  for  EHS  support. 


Test  38:  Examine  status  bits  1,  13,  24,  35,  and  46  in  register  60I6.  At 

least  one  of  the  bits  must  be  non-zero. 

Correct  condition:  At  least  one  of  the  status  bits  1,  13,  24,  35,  or  46  in  register 
6016  must  be  non-zero. 

Error  condition:  All  data  field  status  bits  in  EHS  register  6016  cleared  to  0.  No 
valid  data  in  the  register. 
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If  the  status  bit  for  a  data  field  is  zero  (indicating  that  there  is  no  current  data  for  that  field), 
then  the  data  bits  for  the  field  should  be  cleared  to  all  zeroes. 


Test  39:  Examine  status  bits  1,  13,  24, 35,  and  46  in  register  60|6.  If 

any  status  bit  is  zero,  then  its  corresponding  data  bits  must 
also  be  zero. 

Correct  condition:  (a)  If  bit  1  is  zero,  then  bits  2...12  must  be  zero. 

(b)  If  bit  13  is  zero,  then  bits  14...23  must  be  zero. 

(c)  If  bit  24  is  zero,  then  bits  25. ..34  must  be  zero. 

(d)  If  bit  35  is  zero,  then  bits  36...4S  must  be  zero. 

(e)  If  bit  46  is  zero,  then  bits  47. ..56  must  be  zero. 

Error  condition:  Status  bit(s)  cleared  to  0,  but  corresponding  data  fields  not 
cleared  to  0  in  EHS  register  60)6;  invalid  register  contents 


Note:  if  the  input  surveillance  source  provides  ASTERIX  Category  048  target  reports  (see  [5]), 
then  the  contents  of  the  extracted  register  60i6  are  available  in  Data  Item  250  as  described  in 
Figure  1-2. 

9.1  Magnetic  Heading 

If  status  bit  1  is  cleared  to  zero  (indicating  that  no  magnetic  heading  data  is  available),  then 
bits  2  through  12  must  be  cleared  to  zero.  (This  is  covered  in  test  39(a)  of  Section  9.0.)  If  status 
bit  1  is  set,  then  the  signed  magnetic  heading  value  in  degrees  is  extracted  from  register  60 !6  as 
follows: 

(1)  Extract  bit  2  as  SIGN 

(2)  Extract  bits  3  through  12  as  VAL 

(3)  IfSIGN=l,  then  VAL  =  VAL- 210 

(4)  Magnetic  Heading  (degrees)  =  (VAL  *  180)  /  210 

Magnetic  heading  has  the  range  of  values  -180...  180  degrees  measured  with  respect  to  magnetic 
north.  By  convention,  negative  angles  indicate  counterclockwise  (west). 

The  magnetic  heading  of  an  aircraft  is  related  (but  not  identical)  to  the  aircraft’s  true  track 
angle  (Section  8.2).  First  of  all,  the  magnetic  heading  is  measured  with  respect  to  magnetic  north 
at  the  aircraft’s  location  while  the  true  track  angle  is  measured  with  respect  to  geographic  north. 
As  was  described  in  Section  8.2,  the  offset  between  geographic  and  magnetic  north  is  a  parameter 
of  the  Mode  S  ground  sensor  location.  For  sensors  not  too  close  to  the  Earth’s  poles,  using  the 
magnetic  deviation  value  at  the  sensor  is  precise  enough  (the  magnetic  deviation  wouldn’t  vary 
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more  than  a  degree  over  the  coverage  volume  of  the  sensor).  A  more  precise  map  of  magnetic 
deviation  versus  aircraft  location  (determined  from  its  surveillance  track)  could  be  used. 
Secondly,  the  aircraft’s  heading  is  impacted  by  the  local  winds  at  the  aircraft’s  location  -  it  will 
differ  from  the  ground-measured  true  track  angle  just  as  the  airspeed  values  (Sections  8.5,  9.2, 
and  9.3)  will  differ  from  the  ground  speed  (Section  8.3). 

A  full  validation  of  the  magnetic  heading  value  is  possible  if  the  particular  aircraft 
populates  the  routine  meteorological  register  44|6  (see  Appendix  G).  This  register  provides  the 
values  of  wind  speed  and  direction  measured  on  the  aircraft  itself.  Alternatively,  the  magnetic 
heading  value  would  be  validated  through  a  coordinated  test  procedure  where  the  aircraft  would 
fly  at  known  airspeeds. 

If  a  large  population  of  ELS/EHS-cquipped  aircraft  is  in  the  coverage  of  the  Mode  S 
ground  sensor,  it  may  be  possible  to  build  up  a  database  of  wind  vector  data  by  computing  the 
offsets  between  ground  speed/true  track  angle  and  airspeed/magnetic  heading.  This  estimate  of 
the  current  winds  (a  function  of  position  and  altitude)  could  be  used  to  convert  the  surveillance- 
validated  aircraft  information  (ground  speed  and  true  track  angle)  into  measures  of  aircraft- 
derived  data. 


Test  40:  Compare  the  Magnetic  Heading  value  in  register  60)6  with 

the  surveillance-derived  track  angle  for  the  aircraft 
corrected  to  magnetic  north  (if  required).  The  test  is  not 
performed  if  the  surveillance  track  is  not  yet  fully  mature. 
The  effect  of  local  winds  on  the  aircraft  heading  must  be 
accounted  for.  This  may  be  done  via  extraction  of  the 
aircraft-measured  wind  data  (see  Appendix  G),  having  the 
aircraft  fly  a  known  magnetic  heading,  or  other  means. 

Correct  condition:  The  magnitude  of  the  difference  between  the  Magnetic 

Heading  value  in  register  60w,  and  the  surveillance-derived 
track  angle  for  the  aircraft  (referenced  to  magnetic  north 
and  corrected  for  the  local  winds  at  the  aircraft)  must  be  less 
than  the  heading  sigma  threshold  as  defined  in  Section  3.4. 

If  the  local  wind  data  is  not  available  (or  correctable),  then 
this  test  cannot  be  performed. 

Error  condition:  Magnetic  Heading  field  in  EHS  register  60,,.  is  inconsistent 
with  aircraft  state  data  derived  from  surveillance  and/or 
aircraft-specific  test  inputs. 
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9.2  Indicated  Airspeed  (IAS) 

If  status  bit  13  is  cleared  to  zero  (indicating  that  no  indicated  airspeed  data  is  available), 
then  bits  14  through  23  must  be  cleared  to  zero.  (This  is  covered  in  test  39(b)  of  Section  9.0.)  If 
status  bit  13  is  set,  then  the  indicated  airspeed  value  in  knots  is  extracted  from  register  60)6  as 
follows: 


(1)  Extract  10  bits  14  through  23  as  VAL 

(2)  Indicated  Airspeed  (knots)  =  VAL 

The  LSB  of  the  indicated  airspeed  value  is  2  knots.  If  the  actual  indicated  airspeed  of  the  aircraft 
exceeds  1023  knots,  then  the  indicated  airspeed  value  reported  in  the  register  will  be  limited  to 
1023  knots. 

As  is  described  in  Appendix  F  of  this  report,  the  indicated  airspeed  value  is  a  function  of 
the  local  winds  at  the  aircraft’s  location,  the  aircraft’s  barometric  altitude,  and  the  air  temperature 
at  the  aircraft’s  location.  The  ground  Mode  S  sensor  has  available  the  aircraft’s  barometric 
altitude  data  from  surveillance.  The  air  temperature  can  be  approximated  for  an  ISA  standard  day 
using  the  equation  given  in  Appendix  F.  However,  there  is  no  direct  way  for  the  ground  Mode  S 
sensor  to  determine  the  local  winds.  Hence,  there  is  no  way  to  directly  validate  the  indicated 
airspeed  value  with  surveillance  data.  However,  since  an  aircraft  whose  avionics  are  supporting 
EHS  also  provides  values  of  true  airspeed  (Section  8.5)  in  register  50)6  and  Mach  (Section  9.3)  in 
register  60i6,  it  is  possible  to  employ  the  techniques  from  Appendix  F  of  this  report  to  check  the 
three  airspeed  values  for  consistency.  Given  a  known  altitude  and  any  two  airspeed  values,  it  is 
possible  to  derive  the  air  temperature.  (Alternatively,  just  use  the  ISA  standard  day  temperature 
value.)  With  all  three  airspeed  values,  a  crosscheck  that  each  pair  yields  the  same 
temperature  (and  that  it  is  in  reasonable  agreement  with  the  ISA  standard  day  value)  may  be  used 
to  validate  the  indicated  airspeed  value.  The  speed  variation  threshold  value  to  be  used  is  defined 
in  Section  3.5. 

A  full  validation  of  the  indicated  airspeed  value  is  possible  if  the  particular  aircraft 
populates  the  routine  meteorological  register  44[6  (see  Appendix  G).  This  register  provides  the 
values  of  wind  speed/direction  and  air  temperature  measured  on  the  aircraft  itself.  Alternatively, 
the  indicated  airspeed  value  would  be  validated  through  a  coordinated  test  procedure  where  the 
aircraft  would  fly  at  known  airspeeds. 
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If  a  large  population  of  ELS/EHS-equipped  aircraft  is  in  the  coverage  of  the  Mode  S 
ground  sensor,  it  may  be  possible  to  build  up  a  database  of  wind  vector  data  by  computing  the 
offsets  between  ground  speed/true  track  angle  and  airspeed/magnetic  heading.  This  estimate  of 
the  current  winds  (a  function  of  position  and  altitude)  could  be  used  to  convert  the  surveillance- 
validated  aircraft  information  (ground  speed  and  true  track  angle)  into  measures  of  aircraft- 
derived  data. 


Test  41: 

Compare  the  Indicated  Airspeed  (IAS)  value  in  register  60|6 
with  the  surveillance-derived  ground  speed  for  the  aircraft. 
The  test  is  not  performed  if  the  surveillance  track  is  not  yet 
fully  mature.  The  effect  of  local  winds  and  air  temperature 
on  the  aircraft’s  IAS  must  be  accounted  for.  This  may  be 
done  via  extraction  of  the  aircraft-measured  wind  and 
temperature  data  (see  Appendix  G),  having  the  aircraft  fly  a 
known  IAS,  or  other  means. 

Lacking  the  wind  correction  data,  the  test  would  involve 
comparing  the  three  measures  of  airspeed  provided  by 

EHS  (TAS  in  register  50|6,  IAS  and  Mach  in  register  60|fe)  for 
consistency  via  the  techniques  in  Appendix  F. 

Correct  condition:  The  magnitude  of  the  difference  between  the  Indicated 

Airspeed  (IAS)  value  in  register  60!6  and  the  surveillance- 
derived  speed  for  the  aircraft  (corrected  for  the  local  winds 
and  air  temperature  at  the  aircraft)  must  be  less  than  the 
speed  threshold  as  defined  in  Section  3.5.  If  the  local  w  ind 
and  temperature  data  is  not  available  (or  correctable),  then 
this  test  cannot  be  performed. 

Lacking  the  wind  correction,  check  that  IAS  is  consistent 
with  the  values  of  TAS  in  register  50i6  and  Mach  in  register 
6016  (if  available)  within  the  speed  threshold  as  defined  in 
Section  3.5. 

Error  condition: 

Indicated  Airspeed  field  in  EHS  register  60!6  is  inconsistent 
w  ith  other  measures  of  airspeed. 

9.3  Mach 

If  status  bit  24  is  cleared  to  zero  (indicating  that  no  Mach  number  data  is  available),  then 
bits  25  through  34  must  be  cleared  to  zero.  (This  is  covered  in  test  39(c)  of  Section  9.0.)  If  status 
bit  24  is  set,  then  the  Mach  number  value  is  extracted  from  register  60]6  as  follows: 

( 1 )  Extract  10  bits  25  through  34  as  VAL 

(2)  Mach  number  =  (VAL  *  4)  /  1000 
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The  LSB  of  the  extracted  value  is  0.004  Mach.  If  the  actual  Mach  number  of  the  aircraft  exceeds 
4.092,  then  the  Mach  number  value  reported  in  the  register  will  be  limited  to  4.092. 

As  is  described  in  Appendix  F,  the  Mach  number  value  is  a  function  of  the  local  winds  at 
the  aircraft’s  location,  the  aircraft’s  barometric  altitude,  and  the  air  temperature  at  the  aircraft’s 
location.  The  ground  Mode  S  sensor  has  available  the  aircraft’s  barometric  altitude  data  from 
surveillance.  The  air  temperature  can  be  approximated  for  an  ISA  standard  day  using  the 
equation  given  in  Appendix  F.  However,  there  is  no  direct  way  for  the  ground  Mode  S  sensor  to 
determine  the  local  winds.  Hence,  there  is  no  way  to  directly  validate  the  Mach  number  value 
with  surveillance  data.  However,  since  an  aircraft  whose  avionics  are  supporting  EHS  also 
provides  values  of  true  airspeed  (Section  8.5)  in  register  50!6  and  indicated  airspeed  (Section  9.2) 
in  register  60  )6,  it  is  possible  to  employ  the  techniques  from  Appendix  F  to  check  the  three 
airspeed  values  for  consistency.  Given  a  known  altitude  and  any  two  airspeed  values,  it  is 
possible  to  derive  the  air  temperature.  (Alternatively,  just  use  the  ISA  standard  day  temperature 
value.)  With  all  three  airspeed  values,  a  crosscheck  that  each  pair  yields  the  same 
temperature  (and  that  it  is  in  reasonable  agreement  with  the  ISA  standard  day  value)  may  be  used 
to  validate  the  Mach  number  value.  The  speed  variation  threshold  value  to  be  used  is  defined  in 
Section  3.5. 

A  full  validation  of  the  Mach  number  value  is  possible  if  the  particular  aircraft  populates 
the  routine  meteorological  register  44i6  (see  Appendix  G).  This  register  provides  the  values  of 
wind  speed/direction  and  air  temperature  measured  on  the  aircraft  itself.  Alternatively,  the  Mach 
number  value  would  be  validated  through  a  coordinated  test  procedure  where  the  aircraft  would 
fly  at  known  airspeeds. 
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If  a  large  population  of  ELS/EHS-equipped  aircraft  is  in  the  coverage  of  the  Mode  S 
ground  sensor,  it  may  be  possible  to  build  up  a  database  of  wind  vector  data  by  computing  the 
offsets  between  ground  speed/true  track  angle  and  airspeed/magnetic  heading.  This  estimate  of 
the  current  winds  (a  function  of  position  and  altitude)  could  be  used  to  convert  the  surveillance- 
validated  aircraft  information  (ground  speed  and  true  track  angle)  into  measures  of  aircraft- 
derived  data. 


Test  42: 

Compare  the  Mach  number  value  in  register  60|h  with  the 
surveillance-derived  ground  speed  for  the  aircraft.  The  test 
is  not  performed  if  the  surveillance  track  is  not  yet  fully 
mature.  The  effect  of  local  winds  and  air  temperature  on  the 
aircraft's  Mach  number  must  be  accounted  for.  This  may  be 
done  via  extraction  of  the  aircraft-measured  wind  and 
temperature  data  (see  Appendix  G),  having  the  aircraft  fly  a 
known  Mach  number,  or  other  means. 

Lacking  the  wind  correction  data,  the  test  would  involve 
comparing  the  three  measures  of  airspeed  provided  by 

EHS  (TAS  in  register  50j6,  IAS  and  Mach  in  register  60|A)  for 
consistency  via  the  techniques  in  Appendix  F. 

Correct  condition:  The  magnitude  of  the  difference  between  the  Mach  number 
value  in  register  6016  and  the  surveillance-derived  speed  for 
the  aircraft  (corrected  for  the  local  winds  and  air 
temperature  at  the  aircraft)  must  be  less  than  the  speed 
threshold  as  defined  in  Section  3.5.  If  the  local  w  ind  and 
temperature  data  is  not  available  (or  correctable),  then  this 
test  cannot  be  performed. 

Lacking  the  wind  correction,  check  that  Mach  number  is 
consistent  with  the  values  of  TAS  in  register  50)A  and  IAS  in 
register  60,6  (if  available)  within  the  speed  threshold  as 
defined  in  Section  3.5. 

Error  condition: 

Mach  number  field  in  EHS  register  60, 6  is  inconsistent  with 
other  measures  of  airspeed. 

9.4  Barometric  Altitude  Rate 

If  status  bit  35  is  cleared  to  zero  (indicating  that  no  barometric  altitude  rate  data  is 
available),  then  bits  36  through  45  must  be  cleared  to  zero.  (This  is  covered  in  test  39(d)  of 
Section  9.0.)  If  status  bit  35  is  set,  then  the  signed  barometric  altitude  rate  is  extracted  from 
register  60]6  as  follows: 

( 1 )  Extract  bit  36  as  SIGN 

(2)  Extract  bits  37  through  45  as  VAL 
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(3)  If  SIGN=  1 ,  then  VAL  =  VAL  -  29 

(4)  Barometric  Altitude  Rate  (feet  per  minute)  =  VAL  *  32 

The  LSB  of  the  barometric  rate  field  is  32  feet  per  minute.  By  convention,  positive  altitude  rates 
indicate  an  aircraft  climb.  If  the  aircraft’s  altitude  rate  lies  outside  the  range  of  -16,384  to 
+  16,352  feet/minute,  then  the  extracted  value  is  limited  to  the  appropriate  range  extreme. 

The  barometric  altitude  rate  extracted  from  register  60lh  is  validated  by  comparing  it  to  the 
computed  altitude  rate  derived  from  an  altitude  tracker  algorithm  driven  by  the  surveillance 
altitude  reports.  Appendix  C  describes  an  algorithm  derived  from  the  Mode  S  Traffic 
Information  Service  (TIS)  application  suitable  for  100-foot  flight  level  altitude  data,  while 
Appendix  D  describes  an  algorithm  derived  from  the  ACAS  application  to  be  used  with  25-foot 
altitude  data.  It  should  be  noted  that  the  altitude  trackers  described  in  Appendices  C  and  D  take 
three  surveillance  updates  before  a  stable  altitude  rate  value  is  available.  No  altitude  validation 
tests  should  be  performed  until  the  fourth  surveillance  update.  Appendix  E  describes  a  non  real¬ 
time  algorithm  to  compute  altitude  rate  given  a  recorded  set  of  target  reports.  Valid  altitude  rates 
can  be  computed  using  the  non  real-time  algorithm  described  in  Appendix  E  starting  with  the 
second  target  report. 

Note:  if  the  input  surveillance  source  provides  ASTERIX  Category  048  target 
reports  (see  [4]),  then  the  altitude  obtained  from  Data  Item  090  can  provide  25-foot  resolution  for 
those  aircraft  reporting  25-foot  altitude  data.  The  low-order  14  bits  of  data  item  090  contain  the 
altitude  value  in  25-foot  increments.  The  high-order  two  bits  of  data  item  090  flag  conditions 
where  the  altitude  data  might  be  erroneous.  If  bit  16  (the  validity  indicator)  is  set,  this  indicates 
that  the  altitude  value  is  too  far  from  the  aircraft  track’s  altitude  to  be  trustworthy.  If  bit  15  (the 
garble  indicator)  is  set,  this  indicates  that  a  bit  error  was  detected  in  the  Mode  S  response  and 
error  correction  has  been  attempted.  The  altitude  value  might  not  be  trustworthy. 

The  value  of  the  ‘Dl’  bit  in  the  aircraft  transponder’s  Gray-coded  altitude  bits  indicates 
whether  the  aircraft  is  providing  25-foot  altitude  quantization  (if  set).  (Only  Mode  S  transponders 
can  provide  25-foot  quantization.)  ASTERIX  Category  048  target  reports  (see  [5])  may  provide 
the  Gray-coded  altitude  data  in  Data  Item  100.  Bit  21  of  Data  Item  100  (also  known  as  the  ‘Q’ 
bit)  is  set  to  indicate  25-foot  altimetry. 
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The  test  threshold  for  validating  altitude  rate  is  defined  in  Section  3.8.  The  threshold  value 
is  different  for  aircraft  with  100-foot  versus  25-foot  altitude  quantization. 

Test  43:  Compare  the  Barometric  Altitude  Rate  value  in  register  6016 

with  the  surveillance-derived  altitude  rate  for  the  aircraft. 

The  test  is  not  performed  if  the  surveillance  track  is  not  yet 
fully  mature. 

Correct  condition:  The  magnitude  of  the  difference  between  the  Barometric 
Altitude  Rate  value  in  register  60le>  and  the  surveillance- 
derived  altitude  rate  for  the  aircraft  must  be  less  than  the 
altitude  rate  sigma  threshold  as  defined  in  Section  3.8. 

Error  condition:  Barometric  Altitude  Rate  field  in  EHS  register  6016  is 

inconsistent  with  the  reported  rate  of  change  in  the  aircraft's 
barometric  altitude. 


9.5  Inertial  Vertical  Velocity 

If  status  bit  46  is  cleared  to  zero  (indicating  that  no  inertial  vertical  velocity  data  is 
available),  then  bits  47  through  56  must  be  cleared  to  zero.  (This  is  covered  in  test  39(e)  of 
section  9.0  above.)  If  status  bit  46  is  set,  then  the  signed  inertial  vertical  velocity  is  extracted 
from  register  60i6  as  follows: 

( 1 )  Extract  bit  47  as  SIGN 

(2)  Extract  bits  48  through  56  as  VAL 

(3)  IfSIGN=l,  then  VAL  =  VAL- 29 

(4)  Inertial  Vertical  Velocity  (feet  per  minute)  =  VAL  *  32 

The  LSB  of  the  inertial  vertical  velocity  field  is  32  feet  per  minute.  By  convention,  positive 
vertical  velocities  indicate  climb.  If  the  aircraft’s  inertial  vertical  velocity  lies  outside  the  range 
of  -16,384  to  +16,352  feet/minute,  then  the  extracted  inertial  vertical  velocity  value  is  limited  to 
the  appropriate  range  extreme. 
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When  available,  the  inertial  vertical  velocity  data  is  derived  from  navigation  data 
sources  (such  as  the  FMS)  in  the  aircraft’s  avionics.  These  will  be  different  from  those  providing 
barometric  altitude.  The  inertial  vertical  velocity  has  more  filtering  applied  and  is  likely  to  be 
smoother  than  the  barometric  altitude  rate.  However,  for  purposes  of  validation,  the  same 
procedure  as  that  used  for  barometric  altitude  rate  (see  Section  9.4)  is  to  be  applied. 

Test  44:  Compare  the  Inertial  Vertical  Velocity  value  in  register  6016 

with  the  surveillance-derived  altitude  rate  for  the  aircraft. 

The  test  is  not  performed  if  the  surveillance  track  is  not  yet 
fully  mature. 

Correct  condition:  The  magnitude  of  the  difference  between  the  Inertial  Vertical 
Velocity  value  in  register  60]6  and  the  surveillance-derived 
altitude  rate  for  the  aircraft  must  be  less  than  the  altitude 
rate  sigma  threshold  as  defined  in  Section  3.8. 

Error  condition:  Inertial  Vertical  Velocity  field  in  EHS  register  60|6  is 

inconsistent  with  the  rate  of  altitude  change  computed  using 
altitude  data  from  ground-based  surveillance. 
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APPENDIX  A 

MODE  S  REGISTER  LAYOUTS  FROM  ICAO  DOC  9871 


This  Appendix  contains  reproductions  of  the  register  format  tables  from  ICAO  DOC  9871 
(FIRST  EDITION,  POST  KOBE),  “Technical  Provisions  for  Mode  S  Services  and  Extended 
Squitter”  (Reference  [2]).  These  tables  are  reproduced  here  for  ease  of  reference  as  they  arc 
discussed  in  this  document;  please  see  the  published  ICAO  DOC  9871  for  complete  and  final 
descriptions  of  the  contents  of  the  registers. 

NOTE  1:  the  text  accompanying  the  tables  in  this  Appendix  make  references  to  other  text 
and  sections  within  DOC  9871  [2],  not  to  text  or  references  within  this  document. 

NOTE  2:  the  ICAO  standards  documentation  uses  a  different  notation  for  hexadecimal 
BDS  identifiers  than  that  used  in  this  report.  ICAO  uses  the  notation  m,n  where 'm'  and  ‘n’ 
denote  4-bit  digits.  Hence,  GICB  register  17,6  would  be  denoted  1,7  in  this  appendix. 
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MB  FIELD 


1 

2 

3 

4 

5 

6 

7 

8 

MSB 

BDS  Code  1,0 

LSB 

9 

10 

11 

12 

13 

14 

15 

Continuation  flag  (see  9) 

RESERVED 

16 

Reserved  for  ACAS 

17 

MSB 

18 

19 

20 

Mode  S  subnetwork  version  number  (see  12) 

21 

22 

23 

LSB 

24 

Transponder  enhanced  protocol  indicator  (sec  4) 

25 

Mode  S  specific  services  capability  (see  2) 

26 

MSB 

27 

Uplink  ELM  average  throughput  capability  (see  13) 

28 

LSB 

29 

Downlink  ELM:  throughput  capability  of  downlink  ELM 

30 

containing  the  maximum  number  of  ELM  segments  that  the 

31 

transponder  can  deliver  in  response  to  a  single  requesting 

32 

interrogation  (UF  =  24).  (see  14) 

33 

Aircraft  identification  capability  (see  11) 

34 

Squitter  capability  subficld  (SCS)  (see  5) 

35 

Surveillance  identifier  code  (SIC)  (see  6) 

36 

Common  usage  GICB  capability  report  (see  7) 

37 

38 

RESERVED  FOR  ACAS 

39 

40 

41 

MSB 

42 

43 

44 

45 

46 

47 

Bit  array  indicating  the  support  status  of  DTE 

48 

Sub-addresses  0  to  15  (see  3  and  8) 

49 

50 

51 

52 

53 

54 

55 

56 

LSB 

PURPOSE:  To  report  the  data  link  capability  of  the  Mode  S 

transponder/data  link  installation. 

The  coding  of  this  register  shall  conform  to: 

1)  Annex  10  Volume  IV,  §3. 1 .2.6. 10.2. 

2)  When  bit  25  is  set  to  1,  it  shall  indicate  that  at  least  one  Mode  S 
specific  service  (other  than  GICB  serv  ices  related  to  registers  02  |h, 
03 ih,  04|6,  10|6,  17|6  to  1C|6,  20|(,  and  30|6)  is  supported  and  the 
particular  capability  reports  shall  be  checked. 

Note.  -  Registers  accessed  by  BDS  Codes  0,2;  0,3;  0.4;  1.0;  1,7  to 
l.C;  2,0  and  3.0  do  not  affect  the  setting  of  bit  25. 

3)  Starting  from  the  MSB,  each  subsequent  bit  position  shall 
represent  the  DTE  subaddress  in  the  range  from  0  to  15. 

4)  The  enhanced  protocol  indicator  shall  denote  a  Level  5  transponder 
when  set  to  1 ,  and  a  Level  2  to  4  transponder  when  set  to  0. 

5)  The  squitter  capability  subfield  (SCS)  shall  be  set  to  1  if  both 
registers  05 and  06|6  have  been  updated  within  the  last  ten,  plus 
or  minus  one,  seconds.  Otherwise,  it  shall  be  set  to  0. 

Note.  -  Registers  05 ^  and  06 /6  are  used  for  the  extended  squitter 
Airborne  and  surface  position  re/wrts.  respectively. 

6)  The  surveillance  identifier  code  (SIC)  bit  shall  be  interpreted  as 
follows: 

0  =  no  surveillance  identifier  code  capability 
1  =  surveillance  identifier  code  capability 

7)  Bit  36  shall  be  toggled  each  time  the  common  usage  GICB 
capability  report  (register  17i6)  changes.  To  avoid  the  generation 
of  too  many  broadcast  capability  report  changes,  register  17)6  shall 
be  sampled  at  approximately  one  minute  intervals  to  check  for 
changes. 

8)  The  current  status  of  the  on-board  DTE  shall  be  periodically 
reported  to  the  GDLP  by  on-board  sources.  Since  a  change  in  this 
field  results  in  a  broadcast  of  the  capability  report,  status  inputs 
shall  be  sampled  at  approximately  one  minute  intervals. 

9)  In  order  to  determine  the  extent  of  any  continuation  of  the  data  link 
capability  report  (into  those  registers  reserved  for  this  purpose: 
register  1 1 16  to  register  16j6),  bit  9  shall  be  reserved  as  a 
continuation  flag  to  indicate  if  the  subsequent  register  shall  be 
extracted.  For  example:  upon  detection  of  bit  9  =  1  in  register  10|6, 
then  register  1 1 |6  shall  be  extracted.  If  bit  9  =  1 ,  in  register  1 1  lh, 
then  register  1 2Ih  shall  be  extracted,  and  so  on  (up  to  register  16lfl). 
Note  that  if  bit  9  =  1  in  register  16u„  then  this  shall  be  considered 
as  an  error  condition. 

(Requirements  are  continued  on  the  next  page) 


Figure  A-l.  Data  Link  Capability  Report  (BDS  Code  1,0). 
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10)  The  Mode  S  transponder  may  update  bits  1-8,  16,  33,  35  and  37-40 
independent  of  the  ADLP.  These  bits  arc  provided  by  the  transponder  when 
the  data  link  capability  report  is  broadcast  as  a  result  of  a  transponder  dctcctct 
change  in  capability  reported  by  the  ADLP  (§3.1.2  of  Annex  10  Volume  IV). 

1 1 )  Bit  33  indicates  the  availability  of  Aircraft  Identification  data.  It  shall  be  set  1 
the  transponder  if  the  data  comes  to  the  transponder  through  a  separate 
interface  and  not  through  the  ADLP. 

12)  The  Mode  S  subnetwork  version  number  shall  be  coded  as  follows: 


Version 

Number 

Year  of  Annex  10 
amendment 

Edition  of  this 
document 

0 

Mode  S  subnetwork  not  available 

1 

1996 

— 

2 

1998 

— 

3 

2002 

— 

4 

2007 

Edition  1 

5-127 

Unassigned 

Note.  RTCA/DO-181D .  EUROCAE  ED-73C  and  ED-101  A  are  consistent 
with  ICAO  Doc  9871.  Edition  1. 

1 3)  Uplink  ELM  average  throughput  capability  shall  be  coded  as  follows: 

0  =  No  UELM  Capability 

1  =16  UELM  segments  in  1  second 

2  =16  UELM  segments  in  500  ms 

3  =16  UELM  segments  in  250  ms 

4  =16  UELM  segments  in  125  ms 

5  =  16  UELM  segments  in  60  ms 

6  =16  UELM  segments  in  30  ms 

7  =  Unassigned 

14)  Downlink  ELM  throughput  capability  shall  be  coded  as  follows: 

0  =  No  DELM  Capability 

1  =  One  4  segment  DELM  every  second 

2  =  One  8  segment  DELM  every  second 

3  =  One  16  segment  DELM  every  second 

4  -  One  16  segment  DELM  every  500  ms 

5  =  One  16  segment  DELM  every  250  ms 

6  =  One  16  segment  DELM  every  125  ms 

7-15  =  Unassigned 


Figure  A-l (continued).  Data  Link  Capability  Report  (BDS  Code  1.0). 
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MB  FIELD 


1 

0,5  Extended  squittcr  sirbomc  position 

2 

0,6  Extended  squittcr  surface  position 

3 

0,7  Extended  squittcr  status 

4 

0,8  Extended  squittcr  type  and  identification 

5 

0,9  Extended  squitter  airborne  velocity  information 

6 

0,A  Extended  squitter  event-driven  information 

7 

2,0  Aircraft  identification 

8 

2,1  Aircraft  registration  number 

9 

4.0  Selected  vertical  intention 

10 

4,1  Next  waypoint  identifier 

11 

4,2  Next  waypoint  position 

12 

4,3  Next  waypoint  information 

13 

4,4  Meteorological  routine  report 

14 

4,5  Meteorological  hazard  report 

15 

4.8  VHF  channel  report 

16 

5.0  Track  and  turn  report 

17 

5,1  Position  coarse 

18 

5,2  Position  fine 

19 

5,3  Air-referenced  state  vector 

20 

5,4  Waypoint  1 

21 

5,5  Waypoint  2 

22 

5,6  Waypoint  3 

23 

5,F  Quasi-static  parameter  monitoring 

24 

6,0  Heading  and  speed  report 

25 

Reserved  for  aircraft  capability 

26 

Reserved  for  aircraft  capability 

27 

E,i  Reserved  for  Mode  S  BITE  (Built  In  Test  Equipment) 

28 

E,2  Reserved  for  Mode  S  BITE  (Built  In  Test  Equipment) 

29 

F,  1  Military  applications 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

RESERVED 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

PURPOSE:  To  indicate  common  usage  GICB  services  currently 

Supported. 

1 )  Each  bit  position  shall  indicate  that  the  associated  register  is 
available  in  the  aircraft  installation  when  set  to  1. 

2)  All  registers  shall  be  constantly  monitored  at  a  rate  consistent  with 
their  individual  required  update  rate  and  the  corresponding 
capability  bit  shall  be  set  to  1  only  w  hen  valid  data  is  being  input 
to  that  register  at  the  required  rate  or  above. 

3)  The  capability  bit  shall  be  set  to  a  1  if  at  least  one  field  in  the 
register  is  receiving  valid  data  at  the  required  rate  with  the  status 
bits  for  all  fields  not  receiving  valid  data  at  the  required  rate  set  to 
ZERO  (0). 

4)  Registers  1 8i6  to  1Ci6  shall  be  independent  of  register  1716. 


Figure  A-2.  Common  Usage  GICB  Capability  Report  (BDS  Code  1, 7). 
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MB  FIELD 


16 


17 

18 

19 

20 
21 
22 

23 

24 


25 

26 

27 

28 

29 

30 

31 

32 


33 

34 

35 

36 

37 

38 

39 

40 


41 

42 

43 

44 

45 

46 

47 

48 


49 

50 

51 

52 

53 

54 

55 

56 


4 

BPS  3,5 

represents  has  been  implemented  in  the  aircraft  installation 

5 

BPS  3,4 

when  set  to  1 . 

6 

BPS  3,3 

7 

BPS  3,2 

Starting  from  the  LSB,  each  bit  position  shall  represent  the 

8 

BPS  3,1 

register  number,  in  accordance  with  the  following  table: 

9 

BPS  3,0 

10 

BPS  2,F 

BDS  Code 

Capability  installed  for  register 

11 

BPS  2,E 

BPS  1,8 

01  io  to  38 16 

12 

BPS  2,P 

BPS  1,9 

39|ft  to  70|6 

13 

BPS  2,C 

BPS  1,A 

71  m,  to  A8k, 

14 

BPS  2.B 

BPS  l.B 

A9,6  to  E0,„ 

15 

BPS  2,A 

BPS  1,C 

El i6  to  FF,6 

BPS  3,8 


BPS  3,7 


BPS  3,6 


BPS  2.9 


BPS  2,8 


BPS  2,7 


BPS  2,6 


BPS  2.5 


BPS  2,4 


BPS  2,3 


BPS  2,2 


BPS  2,1 


BPS  2,0 


BPS  1,F 


BPS  1  ,E 


BPS  l.P 


BPS  1,C 


BPS  l.B 


BPS  1,A 


BPS  1,9 


BPS  1,8 


BPS  1,7 


BPS  1,6 


BPS  1,5 


BPS  1,4 


BPS  1,3 


BPS  1,2 


BPS  1,1 


BPS  1,0 


BPS  0.F 


BPS  0,E 


BPS  0,1) 


BPS  0,C 


BPS  O.B 


BPS  0,A 


BPS  0,9 


BPS  0,8 


BPS  0,7 


BPS  0,6 


BPS  0,5 


BPS  0,4 


BPS  0,3 


BPS  0,2 


BPS  0,1 


PURPOSE:  To  indicate  GICB  services  that  arc  installed 


The  25  most  significant  bits  of  register  1C|„  shall  not  be  used. 


Figure  A-3.  Mode  S  Specific  Services  GICB  Capability  Report  (BDS  Code  1,8). 
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MB  FIELD 


1 

BDS  7,0 

2 

BDS  6,F 

3 

BDS  6,E 

4 

BDS  6,D 

5 

BDS  6,C 

6 

BDS  6,B 

7 

BDS  6,A 

8 

BDS  6,9 

9 

BDS  6,8 

10 

BDS  6,7 

11 

BDS  6,6 

12 

BDS  6,5 

13 

BDS  6,4 

14 

BDS  6,3 

15 

BDS  6,2 

16 

BDS  6,1 

17 

BDS  6,0 

18 

BDS  5,F 

19 

BDS  5,E 

20 

BDS  5,D 

21 

BDS  5,C 

22 

BDS  5,B 

23 

BDS  5, A 

24 

BDS  5,9 

25 

BDS  5,8 

26 

BDS  5,7 

27 

BDS  5,6 

28 

BDS  5,5 

29 

BDS  5,4 

30 

BDS  5,3 

31 

BDS  5,2 

32 

BDS  5,1 

33 

BDS  5,0 

34 

BDS  4,F 

35 

BDS  4,E 

36 

BDS  4,D 

37 

BDS  4,C 

38 

BDS  4,B 

39 

BDS  4,A 

40 

BDS  4,9 

41 

BDS  4,8 

42 

BDS  4,7 

43 

BDS  4,6 

44 

BDS  4,5 

45 

BDS  4,4 

46 

BDS  4,3 

47 

BDS  4,2 

48 

BDS  4,1 

49 

BDS  4,0 

50 

BDS  3,F 

51 

BDS  3,E 

52 

BDS  3,D 

53 

BDS  3,C 

54 

BDS  3,B 

55 

BDS  3,A 

56 

BDS  3,9 

PURPOSE:  To  indicate  GICB  services  that  are  installed 

Each  bit  position  shall  indicate  that  the  GICB  serv  ice  that  it 
represents  has  been  implemented  in  the  aircraft  installation 
when  set  to  1 . 


Figure  A-4.  Mode  S  Specific  Services  GICB  Capability  Report  (BDS  Code  1, 9). 
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MB  FIELD 


1 

MSB 

2 

3 

4 

BDS  Code  2,0 

5 

6 

7 

8 

LSB 

9 

MSB 

10 

11 

CHARACTER  1 

12 

13 

14 

LSB 

15 

MSB 

16 

17 

CHARACTER  2 

18 

19 

20 

LSB 

21 

MSB 

22 

23 

CHARACTER  3 

24 

25 

26 

LSB 

27 

MSB 

28 

29 

30 

CHARACTER  4 

31 

32 

LSB 

33 

MSB 

34 

35 

36 

CHARACTER  5 

37 

38 

LSB 

39 

MSB 

40 

41 

42 

CHARACTER  6 

43 

44 

LSB 

45 

MSB 

46 

47 

48 

CHARACTER  7 

49 

50 

LSB 

51 

MSB 

52 

53 

54 

CHARACTER  8 

55 

56 

LSB 

PURPOSE:  To  report  aircraft  identification  to  the  ground. 

1 )  Annex  1 0,  Volume  IV,  §3. 1 .2.9. 

2)  The  character  coding  to  be  used  shall  be  identical  to  that  defined  in 
Table  3-7  of  Chapter  3,  Annex  10,  Volume  IV. 

3)  This  data  may  be  input  to  the  transponder  from  sources  other  than 
the  Mode  S  ADLP 

4)  Characters  1  -  8  of  this  format  shall  be  used  by  the  extended 
squittcr  application. 

5)  Capability  to  support  this  register  shall  be  indicated  by  setting  bit 
33  in  register  10)h  and  the  relevant  bits  in  registers  1 7if>  and  18,„. 

6)  The  aircraft  identification  shall  be  that  employed  in  the  flight  plan. 
When  no  flight  plan  is  available,  the  registration  marking  of  the 
aircraft  shall  be  used. 


Figure  AS.  Aircraft  Identification  ( BDS  Code  2,0). 
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MB  FIELD 


1 

2 

3 

4 

5 

6 
7 

9 

10 
11 
12 

13 

14 

15 

ii 

17 

18 

19 

20 
21 
22 

23 

24 

25 


MSB 


LSB 

MSB 


LSB 

MSB 


BDS  Code  3,0 


ACTIVE  RESOLUTION  ADVISORIES 


RACs  RECORD 


26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 


LSB _ 

RA  TERMINATED _ 

MULTIPLE  THREAT  ENCOUNTER 

MSB  THREAT-TYPE  INDICATOR 

LSB _ 

MSB 


37 

38 

39 

40 


41 

42 

43 

44 

45 

46 

47 

48 


49 

50 

51 

52 

53 

54 

55 

56 


LSB 


THREAT  IDENTITY  DATA 


PURPOSE:  To  report  resolution  advisories  (RAs)  generated  by 
ACAS  equipment. 

The  coding  of  this  register  shall  conform  to: 

1 )  Annex  10,  Volume  IV,  §43.8.4.2.2. 

2)  Bit  27  shall  mean  RA  terminated  when  set  to  1 . 


Figure  A-6.  ACAS  Active  Resolution  Advisory  (BDS  Code  3,0). 
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MB  FIELD 


1 

2 

3 

4 

5 

6 
7 

9 

10 
11 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 


STATUS _ 

MSB  -  32  768  feet 


MCP/FCU  SELECTED  ALTITUDE 
Range  -  [0,  65  520]  feet 


LSB  -  1 6  feet _ 

STATUS _ 

MSB  32  768  feet 

FMS  SELECTED  ALTITUDE 
Range  =  [0,  65  520]  feet 


22 

23 

24 

25 

26 

27 

28 


LSB  =  16  feet 

STATUS 

MSB  =  204.8  mb 


29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 


BAROMETRIC  PRESSURE  SETTING 
MINUS  800  mb 

Range  =  [0,  410]  mb 


LSB  ~  0.1  mb 


40 

41 

42 

43 

44 

45 

46 

47 

48 


RESERVED 


STATUS  OF  MCP/FCU  MODE  BITS 


49 

50 

51 

52 

53 

54 

55 

56 


VNAV  MODE _ 

ALT  HOLD  MODE  MCP/FCU  Mode  bits 

APPROACH  MODE _ 

RESERVED 


STATUS  OF  TARGET  ALT  SOURCE  BITS 
MSB  TARGET  ALT  SOURCE 
LSB 


PURPOSE:  To  provide  ready  access  to  information  about  the  aircraft's  current 
vertical  intentions,  in  order  to  improve  the  effectiveness  of  conflict  probes  and 
to  provide  additional  tactical  information  to  controllers. 

1 )  Target  altitude  shall  be  the  short-term  intent  value,  at  which  the  aircraft  w  ill  level 
off  (or  has  leveled  off)  at  the  end  of  the  current  maneuver.  The  data  source  that 
the  aircraft  is  currently  using  to  determine  the  target  altitude  shall  be  indicated  in 
the  altitude  source  bits  (54  to  56)  as  detailed  below-. 

Note.  -  This  information  w  hich  represents  the  real  " aircraft  intent.  "  w  hen 

available,  represented  by  the  altitude  control  panel  selected  altitude,  the 
flight  management  system  selected  altitude,  or  the  current  aircra  ft 
altitude  according  to  the  aircraft  s  mode  of  flight  (the  intent  may  not  be 
available  at  all  when  the  pilot  is  flying  the  aircraft). 

2)  The  data  entered  into  bits  1  to  13  shall  be  derived  from  the  mode  control 
pancl/flight  control  unit  or  equivalent  equipment.  Alerting  devices  may  be  used 
to  provide  data  if  it  is  not  available  from  “control"  equipment.  The  associated 
mode  bits  for  this  field  (48  to  51)  shall  be  as  detailed  below. 

3)  The  data  entered  into  bits  14  to  26  shall  de  derived  from  the  flight  management 
system  or  equivalent  equipment  managing  the  vertical  profile  of  the  aircraft 

4)  The  current  barometric  pressure  setting  shall  be  calculated  from  the  value 
contained  in  the  field  (bits  28  to  39)  plus  800  mb. 

When  the  barometric  pressure  setting  is  less  than  800  mb  or  greater  than 
1  209.5  mb,  the  status  bit  for  this  field  (bit  27)  shall  be  set  to  indicate  invalid 
data. 

5)  Bits  48  to  56  shall  indicate  the  status  (see  v}C.2.4.4)  of  the  values  provided  in  bits 
1  to  26  as  fol low's: 

Bit  48  shall  indicate  whether  the  mode  bits  (49,  50  and  5 1 )  arc  already 
being  populated: 

0  =  No  mode  information  provided 
1  =  Mode  information  deliberately  provided 

Bits  49,50  and  51: 

0  =  Not  active 
1  =  Active 

Bit  54  shall  indicate  whether  the  target  altitude  source  bits  (55  and  56)  arc 
actively  being  populated: 

0  =  No  source  information  provided 

I  =  Source  information  deliberately  provided 

Bits  55  and  56  shall  indicate  target  altitude  source: 

00  =  Unknown 

01  =  Aircraft  altitude 

10  =  FCU/MCP  selected  altitude 

I I  ~  FMS  selected  altitude 


Figure  A-7.  Selected  Vertical  Intention  (BDS  Code  4,0). 
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MB  FIELD 


1 

STATUS 

2 

SIGN  1  =  Left  Wing  Down 

3 

MSB  =  45  degrees 

4 

5 

6 

ROLL  ANGLE 

7 

8 

Range  =  [-90,  +  90]  degrees 

9 

10 

11 

LSB  =  45/256  degrees 

12 

STATUS 

13 

SIGN  1  =  West  (c.g.,  315  =  -45  degrees) 

14 

MSB  =  90  degrees 

15 

16 

17 

TRUE  TRACK  ANGLE 

18 

19 

Range  =  [-180,  +180]  degrees 

20 

21 

22 

23 

LSB  =  90/5 1 2  degrees 

24 

STATUS 

25 

MSB  =  1  024  knots 

26 

27 

28 

GROUND  SPEED 

29 

30 

Range  =  [0,  2  046]  knots 

31 

32 

33 

34 

LSB  =  1  024/512  knots 

35 

STATUS 

36 

SIGN  1  =  Minus 

37 

MSB  =  8  degrees/second 

38 

39 

40 

TRACK  ANGLE  RATE 

41 

Range  =  [-16,  +16]  degrccs/sccond 

42 

43 

44 

45 

LSB  =  8/256  degrccs/sccond 

46 

STATUS 

47 

MSB  -  1  024  knots 

48 

49 

50 

TRUE  AIRSPEED 

51 

52 

Range  =  [0,  2  046]  knots 

53 

54 

55 

56 

LSB  =  2  knots 

PURPOSE:  To  provide  track  and  turn  data  to  the  ground  systems. 

1 )  If  the  value  of  the  parameter  from  any  source  exceeds  the  range 
allowable  in  the  register  definition,  the  maximum  allowable  value 
in  the  correct  positive  or  negative  sense  shall  be  used  instead. 

Note  J.  -  This  requires  active  intervention  bv  the  GFM. 

2)  The  data  entered  into  the  register  shall,  whenever  possible,  be 
derived  from  the  sources  that  arc  controlling  the  aircraft. 

3)  If  any  parameter  is  not  available  on  the  aircraft,  all  bits 
corresponding  to  that  parameter  shall  be  actively  set  to  ZERO  by 
the  GFM. 

4)  The  LSB  of  all  fields  shall  be  obtained  by  rounding. 

Note  2.  -  Two  s  complement  coding  is  used  for  all  signed  fields  as 
specified  in  §A.2.2.2. 


Figure  A-8.  Track  and  Turn  Report  (BDS  Code  5,0). 
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MB  FIELD 


1 

STATUS 

2 

SIGN  1  =Wcst  (e  g.,  315  =  -45  degrees) 

3 

MSB  =  90  degrees 

4 

5 

6 

MAGNETIC  HEADING 

7 

8 

Range  =  [- 1 80,  + 1 80]  degrees 

9 

10 

11 

12 

LSB  =  90/512  degrees 

13 

STATUS 

14 

MSB  =  512  knots 

15 

16 

17 

INDICATED  AIRSPEED 

18 

19 

Range  =  [0,  1023]  knots 

20 

21 

22 

23 

LSB  =  1  knot 

24 

STATUS 

25 

MSB  =  2.048  MACH 

26 

27 

28 

MACH 

29 

30 

Range  =  [0,  4.092]  MACH 

31 

32 

33 

34 

LSB  =  2  048/512  MACH 

35 

STATUS 

36 

SIGN  1  =  Below 

37 

MSB  =  8  192  feet/minutc 

38 

39 

40 

BAROMETRIC  ALTITUDE  RATE 

41 

42 

Range  =  [-16  384,  +16  352]  fcct/minute 

43 

44 

45 

LSB  =  8  192/256  =  32  feet/minute 

46 

STATUS 

47 

SIGN  1  Below 

48 

MSB  =  8  192  fcct/minute 

49 

50 

51 

INERTIAL  VERTICAL  VELOCITY 

52 

53 

Range  =  [-16  384,  +16  352]  feet/minutc 

54 

55 

56 

LSB  8  192/256  =  32  feet/minute 

PURPOSE:  To  provide  heading  and  speed  data  to  ground  systems 

1 )  If  the  value  of  a  parameter  from  any  source  exceeds  the  range 
allowable  in  the  register  definition,  the  maximum  allowable  value  in 
the  correct  positive  or  negative  sense  shall  be  used  instead 

Note  1  This  requires  active  intervention  bv  the  GFM 

2)  The  data  entered  into  the  register  shall  whenever  possible  be  derived 
from  the  sources  that  arc  controlling  the  aircraft. 

3)  The  LSB  of  all  fields  shall  be  obtained  by  rounding. 

4)  When  barometric  altitude  rate  is  integrated  and  smoothed  w  ith  inertia 
vertical  velocity  (baro-incrtial  information),  it  shall  be  transmitted  in 
the  Inertial  Vertical  Velocity  field. 

Note  2.  -  Barometric  Altitude  Rate  contains  values  solely  derived 
from  barometric  measurement.  The  Barometric  Altitude 
Rate  is  usually  very  unsteady  and  may  suffer  from 
barometric  instrument  inertia. 

Note  3.  -  The  Inertial  Vertical  Velocity'  is  also  providing  information 
on  vertical  movement  of  the  aircraft  but  it  comes  from 
equipments  (IRS.  AHRS)  using  different  sources  used  for 
navigation.  The  information  is  a  more  filtered  and  smooth 
parameter. 

Note  -4.  -  Two  \s  complement  coding  is  used  for  all  signed  fields  as 
specified  in  §A.2.2.2. 


Figure  A-9.  Heading  and  Speed  Report  (BDS  Code  6.0). 
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APPENDIX  B 

EXAMPLE  HORIZONTAL  TRACKER  ALGORITHMS 


This  appendix  contains  example  horizontal  tracker  algorithms  that  may  be  used  to  derive 
aircraft  velocity  estimates  from  a  sequence  of  position  reports.  Section  B.l  describes  an 
algorithm  that  may  be  applied  real-time  or  to  recorded  data,  while  Section  B.2  describes  a 
non-real-time  algorithm  that  is  to  be  applied  only  to  a  recorded  data  set. 

B.l  Real-Time  Horizontal  Tracker 

The  real-time  horizontal  tracker  algorithm  described  in  this  Appendix  was  originally 
derived  from  [7].  The  pseudo-code  in  this  Appendix  was  taken  from  the  implementation  of  the 
Traffic  Information  Service  (TIS)  deployed  in  all  U.S.  Mode  S  terminal  sensors  (Appendix  XIII 
of  [6]).  The  TIS  horizontal  tracker  employs  an  alpha-beta  algorithm  augmented  with  a  turn 
detection  algorithm  step.  Tracking  is  performed  in  Cartesian  x-y  coordinates.  Three  updates  are 
required  to  fully  initialize  a  track.  This  tracker  maintains  two  sets  of  positions  and  velocities  - 
termed  internal  and  external.  The  internal  values  are  designed  to  provide  effective  turn  sensing, 
while  the  external  values  provide  a  more  accurate  actual  position  for  use  by  tracker  applications. 
The  tracker  algorithm  assumes  that  it  receives  an  input  report  (coast  or  update)  once  per  scan  for 
each  aircraft  under  surveillance.  Each  input  REPORT  structure  contains  at  least  the  following 
fields: 


REPORT. Range 
REPORT. Azimuth 
REPORT. ZR 
REPORT.Time 
REPORT. TrackNo 


Slant  Range  of  latest  update. 
Azimuth  of  latest  update. 
Altitude  of  latest  update, 
Time  of  latest  update,  and 
Track  number. 


The  horizontal  tracker  assumes  the  following  data  elements  are  maintained  for  each  aircraft 
track  in  the  system. 


Internal  x-y  position 
Internal  x-y  velocity 
Vertical  position 
Internal  firmness 
External  x-y  position 
External  x-y  velocity 
External  firmness 
Time  of  last  update 
Horizontal  State 
Turn  State 
Speed 


XPI,YPI 

XDI,YDI 

ZP 

FIRMI 

XPE,YPE 

XDE,YDE 

FIRME 

lastupdtime 

trackstate 

tumstate 

speed 


Each  aircraft  track  has  its  horizontal  state  initialized  to  FIRST  (indicating  that  it  has  seen  no 
updates  as  yet)  and  its  last  update  time  initialized  to  zero.  All  other  initialization  processing  will 
be  described  in  Section  B.1.1. 
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The  horizontal  tracker  processing  begins  by  calculating  the  horizontal  update  time.  The 
time  of  the  current  input  surveillance  data  for  this  aircraft  is  used  as  the  current  time  value. 

dtime_h  =  REPORT . Time  -  TRACK. last_upd_time  horizontal  update 

If  dtimeh  is  less  than  or  equal  to  zero  (indicating  a  software  timing  problem),  then  no 
further  horizontal  tracker  processing  is  done  with  this  input  report.  If  the  aircraft  track  has  seen  at 
least  two  updates,  the  tracks  horizontal  positions  (both  internal  and  external)  are  projected  to  the 
current  time  as  follows  (using  the  internal  velocities  in  order  to  reduce  the  chance  of  possible 
errors  due  to  false  turn  detections). 

dx  =  dt ime_h  *  TRACK. XDI 

dy  =  dt ime_h  *  TRACK. YDI 

TRACK. XP I  =  TRACK. XPE  =  TRACK. XP I  +  dx 

TRACK. YP I  =  TRACK. YPE  =  TRACK. YPE  +  dy 

41 

If  dtime  h  is  greater  than  or  equal  to  2  seconds,  the  track's  lastupdtime  is  set  to  the  report  time. 

If  the  current  input  is  a  coast,  then  the  track  firmnesses  are  updated  as  shown  in  Table  B-l 
and  no  further  horizontal  tracking  processing  is  done. 


Table  B-1 

Horizontal  Tracker  Firmness  Update  for  Coasting 


Current  Firmness 

Firmness  After  Coast 

0 

0 

1 

1 

2 

2 

3 

2 

4 

2 

5 

3 

6 

4 

7 

5 

8 

6 

9 

7 

Otherwise,  if  the  input  message  is  a  track  update,  the  input  handler  converts  the  report 
coordinates  from  range-azimuth  to  x-y.  The  first  step  in  this  conversion  is  to  calculate  the  report 
ground  range  using  the  report  vertical  position,  ZR.  (Note:  the  track’s  vertical  position  and 
velocity  processing  are  described  in  Appendix  C  (for  100-foot  flight-level  altitudes).  Appendix 
D  (for  25-foot  altitudes),  and  Appendix  E  (for  non  real-time  processing)).  Two  altitude 
consistency  checks  are  performed  as  follows: 

1)  If  the  absolute  value  of  the  difference  between  the  report  altitude  ZR  and  the  track 
altitude  TRACK.ZP  is  greater  than  9000  feet,  then  TRACK.ZP  is  used  instead  of  ZR 
in  computing  ground  range. 


72 


2)  If  the  altitude  rate  (absolute  altitudereg  difference  divided  by  the  altitude  update  period 
dtimez)  is  greater  than  or  equal  to  85  feet/second,  then  TRACK.ZP  is  used  instead  of 
ZR  in  computing  ground  range. 

These  checks  prevent  altitude  errors  from  causing  overflow  problems  later  in  the  tracker. 
Ground  range  and  the  input  report  azimuth  are  used  to  compute  the  report  x-y 
coordinates  (denoted  REPORT.XR,  REPORT. YR  here).  Next,  the  tracker  is  called  to  update  the 
horizontal  components  of  the  track. 

B.I.l  Initialization  State 

The  horizontal  track  update  to  a  track  whose  horizontal  track  state  is  FIRST  is  done  as 
follows: 

1 )  Set  the  internal  x-y  track  positions  to  report  x-y  position, 

2)  Set  the  external  x-y  track  positions  to  report  x-y  position, 

3)  Set  the  track  vertical  position  to  report  vertical  position,  and 

4)  Update  the  horizontal  track  state  to  SECOND 

B.1.2  Second  Report  State 

The  horizontal  track  update  to  a  track  whose  horizontal  track  state  is  SECOND  repeats 
steps  (1)  through  (3)  of  the  FIRST  state  above.  Next,  the  horizontal  track  state  is  updated  to 
THIRD.  The  track  tum  state  is  initialized  to  NOTURN  and  the  horizontal  tracker  computes  the 
x-y  velocity  components: 

xvel  =  (REPORT.XR  -  TRACK. XPE)  /  dtime_h 

yvel  =  (REPORT. YR  -  TRACK. YPE)  /  dtime_h 

A  check  is  made  that  these  velocities  are  reasonable.  If  either  velocity  is  greater  than  or 
equal  to  2000  knots  (indicating  a  software  problem,  probably  in  the  computed  value  of  dtimeh), 
the  track  state  is  reset  to  FIRST.  Otherwise,  the  track  horizontal  velocity  values  are  initialized  as 
follows: 

XDI  =  XDE  =  xvel 

YDI  =  YDE  =  yvel 

TRACK. speed  =  ( xvel ^  +  yvel 2)05 

B.1.3  Mature  Track  State 

Tracks  whose  track  state  is  neither  FIRST  nor  SECOND  perform  their  horizontal  track 
update  as  described  here.  The  track  state  is  set  to  MATURE.  The  horizontal  tracker  uses  an 
alpha-beta  smoothing  algorithm  to  update  the  track  horizontal  positions.  A  turn  detection 
algorithm  is  used  to  further  update  the  track  velocities  if  a  turn  is  detected.  Both  the  internal  and 
external  track  position  estimates  are  propagated  into  the  future.  The  reason  for  these  two  types  of 
estimates  is  that  the  internal  positions  are  designed  to  provide  effective  turn  sensing,  while  the 
external  estimates  provide  more  accurate  actual  positions  for  the  alert  generation  process.  The 
track’s  ground  speed  is  also  calculated  here. 
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B.  1.3.1  Smoothing/Prediction 

The  smoothing  and  prediction  processing  of  the  tracker  uses  a  standard  alpha-beta 
algorithm  as  described  below.  The  alpha  and  beta  values  used  are  a  function  of  the  track  firmness 
values  as  defined  in  the  Table  B-2.  (These  values  were  derived  empirically.)  The  table  also 
includes  the  new  firmness  to  use  as  a  result  of  the  update  process. 


Table  B-2 

Alpha,  Beta,  and  Firmness  Updates 


Firmness 

Alpha 

Beta 

New  Firmness 

0 

1.000 

0.000 

2 

1 

1.000 

1.000 

3 

2 

1.000 

1.000 

3 

3 

0.833 

0.700 

4 

4 

0.700 

0.409 

5 

5 

0.600 

0.270 

6 

6 

0.524 

0.192 

7 

7 

0.464 

0.144 

8 

8 

0.417 

0.122 

9 

9 

0.400 

0.100 

9 

A  reasonability  test  is  applied  to  the  track  horizontal  speeds.  If  the  track  has  appeared  to  move  at 
an  unreasonable  speed  (i.e.,  more  than  2000  knots),  no  further  smoothing  or  turn  detection  will  be 
performed.  (Note:  in  general,  such  excessive  apparent  speeds  are  the  result  of  timing  or 
correlation  errors  in  the  sensor's  input  data.  This  test  protects  against  overflows,  etc.  in  the 
horizontal  tracking  procedures.) 

test  =  2000  knots  *  dtime_h  maximum  legal  distance  allowed 
DIX  =  RE PORT. XR  -  TRACK. XP I 
DIY  =  REPORT. YR  -  TRACK. YPI 
IF  (I DIX I  <  test)  AND  (I DIY I  <  test)  THEN 
Track  speeds  will  be  reasonable,  do  smoothing  and  turn  detection 
alpha  =  alphaTable [TRACK. FIRMI]  From  Table  B-2 
beta  =  betaTable [TRACK. FIRMI] 

XA  =  TRACK. XPI  +  alpha  *  DIX 
YA  =  TRACK. YPI  +  alpha  *  DIY 
XDA  =  TRACK. XDI  +  (beta  *  DIX  /  dt ime_h) 

YDA  =  TRACK. YDI  +  (beta  *  DIY  /  dt ime_h) 

Perform  turn  detection  algorithm  (see  section  B. 1.3.2  below) 

TRACK. XPI  =  XA 

TRACK. YPI  =  YA 

DEX  =  REPORT. XR  -  TRACK. XPE 

DEY  =  REPORT. YR  -  TRACK. YPE 

alpha  =  alphaTable [TRACK. FIRME]  From  Table  B-2 

TRACK. XPE  =  TRACK. XPE  +  (alpha  *  DEX) 
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TRACK. YPE  =  TRACK. YPE  +  (alpha  *  DEY) 

update  TRACK.  FIRMI  and  TRACK.  FIRME  From  Table  B-2 

B.  1.3.2  Turn  Sensing 

After  the  alpha-beta  smoothing  is  completed,  the  horizontal  tracker  performs  the  turn 
detection  algorithm  to  update  the  horizontal  velocities.  Note  that  tracks  that  have  extremely  small 
speeds  (indicating  an  aircraft  stopped  or  taxiing  on  the  ground)  do  not  go  through  horizontal 
velocity  update.  This  is  done  because  the  velocity  would  be  largely  composed  of  positional 
measurement  noise  and  would  not  be  reliable.  An  empirically  derived  threshold  of  5  knots  is 
used  to  determine  whether  the  horizontal  velocity  update  processing  is  to  be  performed. 

A  =  (DIX  *  TRACK. YD I)  -  (DIY  *  TRACK. XD I) 

S  =  sign (A)  +1,  0,  or  -1 

B  =  TRACK. XD I2  +  TRACK. YDI2 

IF  (B  =  0)  THEN  D2  =  infinity  D2=square  of  cross-track  distance 

ELSE  D2  =  A2  /  B 

R2A  =  XA2  +  YA2 

V2A  =  XDA2  +  YDA2 

TRACK. speed  =  (V2A)05 

IF  (TRACK. speed  >  5  knots)  THEN 

Compute  turn  threshold  for  D2  as  a  function  of  track  range,  speed, 
and  orientation 

STDA  =  150  feet  radial  error  expressed  in  feet 

STDB  =  0.002  *  (R2A)05  tangential  error  expressed  in  feet 

vak  =  (V2A) 05  expressed  in  knots 

DTHA  =  (3.1  *  STDA  +  1.35  *  vak)2 

DTHB  =  (3.1  *  STDB  +  1.35  *  vak)2  -  DTHA 

D2TH  =  DTHA  +  DTHB  *  (XA  *  XDA  +  YA  *  YDA) 2  /  (V2A  *  R2A) 

The  turn  threshold  D2TH  is  multiplied  by  an  empirically  derived  constant  thk  that  is  a 

chosen  from  Table  B-3  based  on  the  track's  firmness.  The  value  of  thk  is  effectively  infinite 
( 1010)  for  track  firmness  values  less  than  3. 


75 


Table  B-3 


THK  Value  as  a  Function  of  Track  Firmness 


Firmness 

THK 

0 

1010 

1 

1010 

2 

1010 

3 

3.60 

4 

2.00 

5 

1.50 

6 

1.26 

7 

1.12 

8 

1.03 

9 

1.00 

thk  =  THK  [TRACK.  FIRM  I]  From  Table  B-3 
D2TH  =  D2TH  *  thk 
IF  (D2  •  D2TH)  THEN 
No  turn  detected,  update  velocities 
TRACK.  turn_state  =  NOTURN 
TRACK.  XD I  =  TRACK.  XDE  =  XDA 
TRACK.  YD  I  =  TRACK.  YDE  =  YDA 
ELSE 

Turn  detected,  compute  velocity  corrections 

DRX  =  DIX  +  dx  dx,dy  calculated  at  start  of  Appendix  B 

DRY  =  DIY  +  dy 
C  =  DRX  *  XDA  +  DRY  *  YDA 
P  =  sign(C) 

CP2  =  C2  /  [  (DRX2  +  DRY2)  *  V2A] 

CT2  =  [cos (20  degree  turn)]2  constant  value 
IF  (P  *  CP2  •  CT2)  THEN 
Default  turn  correction 

SDT  =  sin  (10  degrees  of  turn)  constant  values 
CDT  =  cos  (10  degrees  of  turn) 

ELSE 

Compute  turn  correction 
CP  =  (CP2)0S 

SDT  =  [0.5  *  (1  -  CP)]0'5 

CDT  =  [0.5  *  (1  +  CP)]0'5 

TRACK. XDI  =  XDA  *  CDT  +  (S  *  SDT  *  YDA) 

TRACK. YD I  =  YDA  *  CDT  -  (S  *  SDT  *  XDA) 

IF  (S  =  TRACK. turn_state)  THEN 

Same  direction  as  last  update,  extra  external  turn  correction 
SDEL  =  sin (15  degrees  of  turn)  constant  values 
CDEL  =  cos  (15  degrees  of  turn) 
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TRACK. XDE  =  TRACK. XD I  *  CDEL  +  (S  *  SDEL  *  TRACK. YD I) 

TRACK. YDE  =  TRACK. YD I  *  CDEL  -  (S  *  SDEL  *  TRACK. XDI) 

ELSE 

Not  same  direction  as  last  update 
TRACK. XDE  =  TRACK. XDI 
TRACK. YDE  =  TRACK. YD I 
TRACK. turn_state  =  S 

B.2  Non-Real-Time  Horizontal  Path  Smoother 

The  horizontal  tracker  algorithm  described  in  Appendix  B.l  above  was  designed  to  operate 
in  real-time.  However,  if  all  the  target  reports  for  the  aircraft’s  trajectory  are  simultaneously 
available  (as  from  a  previously  recorded  dataset),  then  a  non-real-time  off-line  algorithm  can  be 
applied  to  gain  a  more-accurate  determination  of  truth  via  the  ability  to  look  both  ahead  and  back 
through  the  data  in  the  processing  of  each  aircraft  track.  For  the  purposes  of  the  discussion  in  this 
appendix,  it  is  assumed  that  the  target  report  positions  for  a  given  aircraft’s  flight  are  accessible 
as  an  array  of  structures  denoted  here  as  TRACK[1...N],  Each  target  report  structure  in  the 
TRACK  array  is  assumed  to  have  the  following  elements: 

(a)  Cartesian  X-coordinate, 

(b)  Cartesian  Y-coordinate,  and 

(c)  Time  of  measurement. 

The  conversion  of  the  sensor’s  range-azimuth  coordinates  to  Cartesian  coordinates  (the 
origin  is  assumed  to  be  at  the  sensor)  is  done  using  the  aircraft’s  reported  altitude  in  the 
calculation  of  ground  range  (see  Section  3.3).  If  the  target  report  lacks  altitude  data,  then  the 
lesser  of  0.5  nautical  miles  or  one-half  of  the  target  range  is  assumed  for  the  altitude.  The  use  of 
Cartesian  coordinates  make  it  easier  to  compute  the  track’s  velocity  components  and  remove  the 
need  to  be  concerned  with  the  inter-dependence  of  the  sensor’s  range  and  azimuth  measurements 
when  the  aircraft  is  close  to  the  sensor. 

The  non-real-time  horizontal  tracker  algorithm  makes  two  passes  through  the  aircraft  track. 
The  first  pass  is  intended  to  remove  any  outlier  points  that  might  have  resulted  from  faulty 
correlation  processing  or  other  types  of  data  error.  Once  the  outlier  points  have  been  flagged,  a 
second  pass  through  the  track  data  is  used  to  compute  a  smoothed  truth  position  and  track 
velocity  vector  for  each  valid  target  report. 

B.2.1  Outlier  Removal  Pass 

The  outlier  removal  pass  of  the  algorithm  treats  each  data  entry  i  from  TRACK[4]  through 
TRACK[N-3],  A  7-point  quadratic  curve-fit  algorithm  (described  in  B.2. 3)  is  performed  for  each 
set  of  points  (i-3)  through  (i+3)  in  both  Cartesian  coordinates  versus  time.  A  quadratic  fit  is  able 
to  smoothly  follow  an  aircraft’s  turn  without  being  susceptible  to  data  noise.  The  use  of  a  7-point 
fit  has  proven  to  be  a  good  compromise  between  adequate  smoothing  and  responsiveness  to  real 
aircraft  maneuvers. 
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The  smoothed  Cartesian  position  of  the  aircraft  at  the  time  of  target  report  i  is  computed 
(using  the  curve-fit  coefficients  computed  for  report  i)  and  its  separation  distance  from  the  actual 
target  report  position  is  calculated.  Assuming  that  the  quadratic  curve-fit  algorithm  described  in 
B.2.3  has  been  performed  for  both  the  X[]  and  Y[]  coordinates  of  this  point,  the  separation 
distance  for  report  i  is  computed  as  follows: 

Distance  (i)  =  [(XFIT[i]  -  X  [i  ]  ) 2  +  (YFIT  [i]  -  Y[i])2]0'5 

If  this  separation  distance  exceeds  a  reasonability  threshold,  then  TRACK[i]  is  declared  to 
be  an  outlier.  Target  reports  declared  to  be  outliers  are  not  used  in  further  processing.  (Note:  a 
particularly  noisy  track  might  have  too  many  outlier  points  to  be  fit  successfully  using  this 
algorithm.  Some  sort  of  check  for  multiple  outliers  in  a  sequence  of  seven  reports  might  be 
required.  Only  the  track  entry  having  the  largest  separation  distance  (in  the  sequence  of  seven 
reports)  would  be  declared  an  outlier. 

The  outlier  separation  reasonability  threshold  is  calculated  as  a  function  of  the  aircraft’s 
position  with  respect  to  the  sensor  and  the  sensor’s  measurement  accuracy.  Section  3.3  describes 
how  to  compute  the  measurement  error  sigma  values  for  a  surveillance  position  report  in 
Cartesian  coordinates.  A  system  parameter  “n”  (nominally  three)  is  multiplied  by  the  sensor 
measurement  error  sigmas  to  derive  the  outlier  separation  threshold  in  Cartesian  coordinates.  The 
separation  distance  reasonability  threshold  is  given  simply  as: 

Distance  Threshold  =  [  (n  *  SigmaX)2  +  (n  *  SigmaY)2  ]  0,5 

B.2.2  Smoothing  Pass 

Once  the  outliers  have  been  removed  from  the  track  data,  a  second  pass  is  performed  to 
smooth  the  aircraft’s  track  and  derive  the  velocity  components.  As  was  the  case  for  the  outlier 
removal  pass,  each  valid  data  entry  “i”  from  TRACK[4]  through  TRACK[N-3]  is  fit  with  a  7- 
point  quadratic  polynomial  -  from  (i-3)  through  (i+3)  -  as  described  in  B.2.3.  The  smoothed 
position  of  the  aircraft  at  the  time  of  target  report  i  is  computed  -  this  is  considered  the  true 
position  of  the  aircraft  for  this  time. 

The  aircraft’s  track  velocity  components  for  the  time  of  target  report  i  are  computed  from 
the  smoothed  positions  of  the  track  at  time  of  target  reports  (i-1)  and  (i+1)  -  using  the  quadratic 
polynomial  curve-fit  for  time  of  target  report  i.  The  Cartesian  velocity  components  are  given  by: 

DeltaT  =  TRACK [ i + 1 ] .time  -  TRACK [ i - 1 ] .time 

Xdot [i]  =  (TRACK [i+1] . smooth_X  -  TRACK [i - 1] . smooth_X)  /  DeltaT 

Ydot [i]  =  (TRACK [i+1] ,smooth_Y  -  TRACK [i-1] . smooth_Y)  /  DeltaT 

There  needs  to  be  a  protection  test  that  the  computed  value  of  DeltaT  is  non-zero.  If  DeltaT  is 
zero  (indicating  a  likely  timing  problem  in  the  data),  then  set  both  Cartesian  velocity  components 
to  zero. 
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B. 2.3  Quadratic  Curve-Fit  Algorithm 

The  following  pseudo-code  describes  how  to  perform  a  quadratic  (second-order)  curve-fit 
for  a  set  of  seven  data  points,  denoted  here  as  the  arrays  P[7]  (denoting  a  position  in  a  Cartesian 
coordinate  -  either  X[]  or  Y[])  and  Time[7]  (time  for  the  particular  position  coordinate  value). 
The  pseudo-code  in  this  section  is  a  specific  case  of  a  generalized  Gauss-Jordan  algorithm  that  is 
found  in  many  computer  mathematics  packages.  The  pseudo-code  in  this  section  uses  the 
convention  that  array  indices  start  with  0.  The  curve-fit  algorithm  returns  the  following  data: 

PFIT[7]:  The  value  fit  to  each  data  point  (for  the  input  Cartesian  coordinate) 

COEFF[3]:  The  calculated  coefficients  of  the  quadratic  equation  fit  to  the  data 

Quadratic  equations  all  have  3  coefficients  -  constant,  linear,  and  second-order. 

The  first  step  of  the  curve  fitting  process  is  to  initialize  all  the  entries  of  the  coefficient 
array  COEFF[3]  to  zero.  A  copy  of  the  input  data  point  values  is  made  -  denoted  here  as  PC[7]. 
The  copy  of  the  position  values  is  made  so  that  the  subsequent  process  of  curve  fitting  does  not 
impact  the  original  data  values  from  the  calling  program. 

The  second  step  of  the  curve  fitting  process  is  to  compute  the  maximum  and  minimum 
values  in  the  input  data  array  P[7].  The  sum  of  all  the  P[]  entries  (denoted  Psum)  is  also 
computed  here.  This  processing  looks  for  the  special  case  (fairly  common)  of  a  straight  line 
where  the  full  curve-fit  process  is  not  necessary. 

Pmax  =  P  [0] 

Pmin  =  P[0] 

Psum  =  P [0] 

FOR  i=l  THROUGH  6 

IF  P[i]  >  Pmax  THEN  Pmax  =  P[i] 

IF  P[i]  <  Pmin  THEN  Pmin  =  P[i] 

Psum  =  Psum  +  P[i] 

If  the  maximum  and  minimum  values  in  the  input  data  are  nearly  equal  (the  threshold  for 
straightness  of  0.01  nautical  miles  was  chosen  empirically),  then  the  data  is  a  special  case  -  a 
nearly  straight  line.  This  special  case  is  handled  as  follows: 

IF  (Pmax  -  Pmin)  <  0.01  THEN  special  case  for  a  line 

Paverage  =  Psum  /  7.0  average  of  the  coordinate  values 

COEFF [0]  =  Paverage  only  constant  term  is  nonzero 

FOR  i=0  THROUGH  6 

PFIT [i]  =  Paverage 

If  the  data  points  cannot  be  fit  with  a  straight  line,  the  midpoint  P[]  value  (Pmax  -  Pmin)  /  2)  is 
subtracted  from  each  of  the  PC[]  values  in  order  to  normalize  them  and  the  curve-fit  processing 
continues  as  described  below. 
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The  third  step  of  the  curve  fitting  process  is  to  calculate  the  normal  equations.  Three  local 
doubly-dimensioned  arrays  are  used  in  this  computation:  G[3][4],  Q[7][4],  and  PP[3][7],  The 
first  dimension  of  the  G  array  is  degree  of  the  fit  (quadratic  in  this  case)  plus  1 ,  while  the  second 
dimension  is  one  larger.  All  the  elements  of  the  G[][]  array  are  initialized  to  zero.  The  first 
dimension  of  the  Q  array  is  the  number  of  input  data  points  used  in  the  curve-fit  (seven  in  this 
case),  while  the  second  dimension  is  the  degree  of  the  curve-fit  plus  two  (the  extra  storage  holds 
the  Time  values).  The  Q[][]  array  is  initialized  as  follows: 

FOR  i=0  THROUGH  6 

Q[i]  [0]  =1.0 
Q[i]  [3]  =  Time  [i] 


FOR  j=0  THROUGH  1 

FOR  i=0  THROUGH  6 

Q[i]  [j+1]  =  Q [i]  [j]  *  PC [i] 


The  PP[][]  array  is  then  computed  as  the  transpose  of  the  Q[][]  array  as  follows: 

FOR  j  =  0  THROUGH  2 

FOR  i=0  THROUGH  6 

PP[j]  [i]  =  Q[i]  [j] 


The  G[][]  array  is  then  computed  from  the  PP[][]  and  Q[][]  arrays  as  follows: 

FOR  i=0  THROUGH  2 

FOR  j  =  0  THROUGH  3 

FOR  k=0  THROUGH  6 

G[i]  [j]  =  G  [i]  [j ]  +  (PP[i][k]  *  Q  [k]  [j]  ) 


Solving  the  normal  equations  is  done  with  the  Gauss-Jordan  reduction  algorithm  as  follows: 


FOR  k=0  THROUGH  2 

FOR  j  =  (k+1)  THROUGH  3 

G[k]  [j]  =  G[k]  [j]  /  G[k]  [k] 

FOR  i=0  THROUGH  2 

IF  (i-k)  •  0  THEN 

FOR  j= (k+1)  THROUGH  3 

G[i]  [j]  =  G[i]  [j]  -  (G[i]  [k]  *  G[k]  [j]) 
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The  calculated  normal  equation  coefficients  are  then  copied  from  the  G[][]  array  to  the  COEFF[] 
array  as  follows  (this  is  not  required  if  only  the  curve-fit  coordinate  values  denoted  PFIT[] 
described  below  are  used  in  further  processing): 

FOR  k=0  THROUGH  2 

COEFF  [k]  =  G[k]  [3] 

The  fourth  and  final  step  of  the  curve  fitting  process  is  to  compute  the  seven  curve-fitted 
point  values  for  each  of  the  seven  data  points  for  the  input  coordinate  —  denoted  as  the  array 
PFIT[7],  This  process  uses  a  local  array  denoted  ALPHA[7]  that  is  initialized  to  zero.  The  curve 
fitting  procedure  is  done  as  follows  for  each  Cartesian  coordinate  (this  process  uses  the  equation 
coefficients  to  solve  for  each  point): 

FOR  k=0  THROUGH  6 

FOR  i=0  THROUGH  2 

ALPHA  [2-i]  =  G[i]  [3] 

FOR  j=0  THROUGH  1 

ALPHA  [j+l]  =  ALPHA  [j+1]  +  (ALPHA  [j]  *  PC  [k]  ) 

PFIT  [k]  =  ALPHA  [2] 
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APPENDIX  C 

100  FOOT  FLIGHT  LEVEL  VERTICAL  TRACKER  ALGORITHM 


The  vertical  tracker  algorithm  used  in  the  Traffic  Information  Service  (TIS)  is  a  variation 
on  the  algorithm  originally  developed  for  ACAS  applications  (see  [8]).  It  is  a  multi-state 
algorithm  that  measures  the  time  spent  by  a  track  at  each  altitude  level  and  estimates  the  time 
between  altitude  level  transitions.  Such  a  multi-state  procedure  is  better  able  to  generate  accurate 
vertical  velocity  estimates  than  a  simpler  alpha-beta  algorithm  (such  as  that  used  for  the 
horizontal  TIS  tracker),  since  the  altitude  data  is  coarsely  quantized  (to  100-foot  flight  levels)  and 
aircraft  may  spend  large  amounts  of  time  between  level  transitions  -  leading  to  erratic  estimates 
of  the  aircraft’s  altitude  rate.  The  expression  of  the  vertical  tracker  algorithm  in  pseudo-code 
given  this  Appendix  is  derived  from  Appendix  XIII  of  [6].  The  TIS  tracker  assumes  that  it 
receives  an  input  surveillance  target  report  (coast  or  update)  once  per  scan  for  each  aircraft  under 
surveillance. 

The  vertical  tracker  assumes  the  following  data  elements  are  maintained  for  each  aircraft 
track  in  the  system: 


Vertical  position 

ZP, 

Vertical  velocity 

ZD, 

Time  of  last  altitude  update 

altupdtime, 

Altitude  State 

altstate. 

Vertical  position  used  in  last  rate  update 

ZPR, 

Smoothed  altitude  residual 

resid. 

Extent  of  altitude  trend 

alttrendtime, 

Time  of  last  altitude  transition 

alttranstime. 

Time  since  altitude  rate  was  estimated 

altratetime. 

Uncertainty  in  altitude  transition  time 

altguesstime. 

Altitude  transition  since  transition  time 

alt  trans  diff,  and 

Sign  of  last  altitude  transition 

altdirection. 

The  tracker  states  are  denoted: 

INIT  initial  state,  first  time  for  track  or  after  re-initialization, 

GUESS  single  un-reinforced  altitude  transition,  rate  uncertain, 

TREND  an  altitude  trend  has  been  declared, 

LEVEL  level  flight, 

RESET  need  to  reset  the  rate,  residual  got  too  large,  and 
TOZERO  reducing  rate  towards  zero. 


The  altitude  fields  for  each  aircraft  are  initialized  as  follows,  where  scantime  is  the  update 
period  of  the  Mode  S  sensor  providing  the  input  surveillance  reports.  The  parameter  scantimc 
denotes  the  sensor’s  scan  period  in  appropriate  time  units. 

TRACK,  alt  state  =  INIT 
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1  scan  ago 


TRACK.  alt_upd_time  =  REPORT. time  -  scantime 
TRACK. alt_trend_time  =  scantime 
TRACK. alt_trans_time  =  -scantime 
TRACK. alt_rate_time  =  0 
TRACK. resid  =  0 
TRACK. alt_trans_diff  =  0 
TRACK. ZP  =  REPORT. ZR 
TRACK. ZPR  =  REPORT. ZR 
TRACK. ZD  =  0 

C.l  Vertical  Tracker  Driver/Handler 

The  first  step  of  the  vertical  tracker  algorithm  is  to  compute  the  update  and  transition  times 
as  follows: 

dtime_z  =  REPORT. time  -  TRACK.  alt_upd_time  vertical  update 

dtime_trans  =  REPORT. time  -  TRACK. alt_trans_time  transition 

If  dtime  z  is  less  than  or  equal  to  zero,  or  dtimetrans  is  equal  to  zero  (indicating  a 
software  timing  problem),  no  further  track  update  processing  is  done.  If  both  time  computed  time 
periods  are  positive,  the  input  handler  can  proceed  to  compute  a  vertical  position  ZR  from  the 
message  altitude  if  the  input  is  a  track  update  and  the  altitude  type  is  available.  If  the  message  is 
a  coast  or  drop,  or  the  altitude  not  available,  ZR  is  set  to  the  track's  vertical  position 
TRACK.ZP  (if  the  track  is  not  in  its  initial  state),  or  to  the  lesser  of  0.5  nautical  miles  and  one- 
half  of  the  track's  range  (if  the  track  is  in  its  initial  state).  (The  sensor  uses  an  equivalent  altitude 
assumption  in  computing  ground  range  for  aircraft  tracks  that  have  never  had  a  reported  clear 
altitude.) 

The  overall  driver  for  the  altitude  tracker  first  computes  the  altitude  that  the  track  would 
have  if  projected  to  the  current  time. 

coast_alt  =  TRACK. ZPR  +  (dt ime_z  *  TRACK. ZD) 

If  the  report  for  this  update  does  not  have  an  altitude,  or  if  this  update  is  a  coast,  then  the  track's 
vertical  position  is  set  to  coast  alt  and  the  following  check  for  excessive  altitude  coasting 
performed: 

IF  (dt ime_z  >  4  scans)  THEN 
This  track  coasted  too  long,  reset  its  altitude  fields 
TRACK. alt_state  =  INIT 
TRACK. alt_trend_time  =  scantime 
TRACK. alt_trans_time  =  -scantime 
TRACK. alt_rate_time  =  0 
TRACK. resid  =  0 
TRACK. alt_trans_diff  =  0 
TRACK. ZD  =  0 
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If  the  check  passes  and  the  track's  altitude  fields  are  reset,  no  further  altitude  processing  is 
performed. 

Next,  the  altitude  tracker  driver  sets  the  values  of  local  variables  to  be  used  by  the 
processing  for  the  various  altitude  tracker  states  (see  sections  C.2  through  C.5). 

tr ans_diff  =  REPORT.  ZR  -  TRACK.  ZPR 
TRACK.  alt_trans_diff  =  trans_diff 
trans_sign  =  sign  (trans_diff) 
climbing  (+) ,  descending  (-) ,  or  level  (0) 
atrans_diff  =  I trans_diff I 
trans_rate  =  tr ans_diff  /  dtime_trans 

IF  (atrans_diff  •  1  flight  level)  THEN  trans_flag  =  TRUE 
ELSE  trans_flag  =  FALSE 

If  the  track's  altitude  state  is  INITIALIZE,  then  the  processing  for  the  initialization  state  is 
performed  (Section  C.2).  Otherwise,  the  altitude  tracker  checks  that  the  apparent  altitude 
acceleration  is  reasonable.  (This  checking  keeps  erroneous  altitude  jumps  due  to  Mode  C  bit 
errors  from  upsetting  the  tracked  altitude  and  altitude  rate.)  One  flight  level  error  tolerance  is 
allowed. 

alt_diff  =  I  coast_alt  -  REPORT.  ZR  I 
IF  (alt_diff  >  6000  feet)  THEN 

Altitude  jump  too  large,  treat  as  coast,  no  further  processing 
TRACK. ZP  =  REPORT. ZR 
Return 

accel  =  2  *  (alt_diff  -  1  flight  level)  /  dtime_z 2 
IF  (accel  >  64  feet /sec2)  THEN 
Acceleration  too  large  (>  2g) ,  treat  as  coast,  no  further 
processing 
TRACK. ZP  =  REPORT. ZR 
Return 

If  the  value  of  trans  flag  is  TRUE,  then  the  Transition  State  update  procedure  is 
performed  (Section  C.4)  —  otherwise,  the  No  Transition  State  update  procedure  is 
performed  (Section  C.3).  If  the  track's  altitude  state  after  these  procedures  is  TREND  and  the 
absolute  value  of  the  track's  altitude  residual  is  greater  than  1.05  flight  levels  (i.e.,  105  feet),  then 
the  RESET  Smoothing  procedure  is  performed  (Section  C.5). 

For  both  the  INITIALIZATION  and  other  altitude  track  states  (unless  the  track  has  been 
coasted  in  altitude),  the  following  steps  are  performed  to  complete  the  altitude  tracking  function. 

IF  (trans_flag  =  TRUE)  THEN 
Start  of  an  altitude  transition 
TRACK. alt  trans  time  =  REPORT. time 
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TRACK.  alt_direction  =  trans_sign 

TRACK,  al  t_rate_time  =  REPORT,  time  -  TRACK .  alt_upd_time 

TRACK.  alt_upd_time  =  REPORT,  time 

TRACK.  ZP  =  TRACK.  ZPR  =  REPORT .  ZR 

IF  (TRACK.  alt_trend_time  >  16  seconds)  THEN 

TRACK.  alt_trend_time  =  16  seconds  limit  trend  duration 

dt  =  REPORT. time  -  TRACK. alt_trend_time 

IF  (TRACK. al  t_trans_time  <  dt)  THEN  TRACK . alt_trans_time  =  dt 

TRACK. ZP  =  REPORT. ZR 
TRACK. ZPR  =  REPORT. ZR 

C.2  Initialization  State 

The  processing  for  a  track  whose  altitude  state  is  being  initialized  is  performed  as  follows. 
The  initialization  of  the  track  altitude  fields  and  local  variables  was  described  in  Section  C.l. 

IF  (atrans_diff  >  1  flight  level)  THEN 
Have  had  a  significant  altitude  change 
TRACK,  alt _st ate  =  GUESS  unsure  about  altitude  rate 
TRACK. alt_trend_time  =0.2  *  scantime  assume  a  time 

TRACK. ZD  =  ( (atrans_diff  -  0.75  flight  levels)  *  trans_sign)  / 
dtime_trans 

TRACK. residual  =  0.85  *  TRACK. residual  +  TRACK. alt _trans_diff  - 
(TRACK.  ZD  *  dtime_z) 

ELSE 

Basically  level,  no  significant  altitude  change 

TRACK.  alt_trend_time  =  TRACK,  alt __trend_time  -  TRACK,  a  1 1_ rat e_ time 
IF  (REPORT.  alt_type  =  CLEAR_LEVEL)  THEN 

IF  (dtime_trans  >  6  seconds)  THEN  TRACK.  alt_state  =  LEVEL 

C.3  No  Transition  State 

The  processing  for  a  track  update  during  which  there  has  not  been  an  altitude  transition  is 
performed  as  follows.  The  basic  operation  is  to  update  the  track's  altitude  state  variable,  vertical 
velocity,  and  altitude  residual.  The  setting  of  the  local  variables  was  described  in  Section  C.l. 

No  division  by  0 

dtime  =  dtime_trans  -  [1  flight  level  /  (  /  TRACK.  ZD  /  +  l.e-10)] 

IF  (dtime  >2.5  *  scantime)  THEN  TRACK.  alt_state  =  TOZERO 
IF  (dtime_trans  >  15  seconds)  THEN  TRACK.  alt_state  =  LEVEL 
IF  (TRACK.  alt_state  =  RESET)  THEN  TRACK .  alt_st ate  =  TREND 
IF  (TRACK. alt  state  !=  TREND)  THEN 
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TRACK. ZD  =  0.7  *  TRACK. ZD  reduce  the  vertical  velocity 

TRACK.  alt_trend_time  =  TRACK.  alt_trend_time  +  dtime_z 
TRACK,  residual  =  0.85  *  TRACK .  residual  +  TRACK,  alt _trans_diff  - 
(TRACK. ZD  *  dtime_z)  Smooth  the  altitude  residual 

C.4  Transition  State 

The  altitude  tracker  processing  described  below  is  performed  for  a  track  whose  updating 
report  indicates  an  altitude  level  transition  has  occurred  since  the  last  update.  Different 
processing  is  done  depending  on  the  track's  altitude  state.  Setting  of  the  local  variables  was 
described  in  Section  C.l. 

CASE  RESET: 

TRACK.  alt_state  =  TREND  become  a  trend 
CASE  TREND: 

Adjust  trend  time  at  start  of  acceleration 
IF  (t rans_sign  =  TRACK. alt_direct ion)  THEN 
IF  (TRACK. alt_trend_time  >  10  seconds)  THEN 
Check  for  early  altitude  transition 
azd  =  1.0  /  (I  TRACK.  ZD  I  +  l.e-10)  no  divide  by  zero 
dt  =  (1  flight  level  *  dtime_trans  /  atrans_diff)  -  (1  flight 
level  *  azd) 

IF  (dt  <  (-1.42  *  scantime  +  TRACK. alt _guess_time) )  THEN 
Reset  needed  due  to  early  altitude  transition 
TRACK. alt_state  =  RESET 
TRACK. residual  =  0 

TRACK. alt _trend_time  =  dtime_trans  +  (0.2  *  scantime) 

Smooth  the  altitude  residual 

TRACK.  ZD  =  (0.15  *  TRACK.  ZD)  +  (0.85  *  translate) 

Smooth  the  vertical  velocity 

beta  =  1.0  /  (1.0  +  0.75  *  TRACK,  alt _trend_time  /  dtime_trans) 

IF  (beta  <  0.1)  THEN  beta  =  0.1 

TRACK.  ZD  =  (TRACK.  ZD  *  (1.0  -  beta))  +  (beta  *  translate) 

Smooth  the  altitude  residual 

TRACK. residual  =  0.85  *  TRACK. residual  +  TRACK. alt _trans_diff  - 
(TRACK.  ZD  *  dtime__z) 

TRACK.  alt_trend_time  =  TRACK.  alt_trend_time  dtime_z 

CASE  LEVEL: 

TRACK. residual  =  0 
TRACK,  alt _trend_time  =  dtime_z 
IF  (atrans_diff  >  1  flight  level)  THEN 
Beginning  of  an  altitude  trend 
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TRACK.  alt_state  =  TREND 

time  =  dtime_z  +  TRACK.  alt_guess_time 

TRACK.  ZD  =  TRACK.  alt_trans_diff  /  time 

ELSE 

Have  to  guess  at  the  altitude  rate 
TRACK. alt_state  =  GUESS 

TRACK. ZD  =  (0.25  flight  levels)  *  tr ans_sign  /  dtime_trans 

CASE  GUESS:  same  processing  for  both  GUESS  and  TOZERO  states 

CASE  TOZERO: 

IF  (trans_sign  =  TRACK. alt_direct ion)  THEN 
Current  trend  is  continuing 
TRACK.  alt_state  =  RESET 

time  =  (0.2  *  scantime)  +  (0.5  *  TRACK. alt _guess_time) 

IF  (atrans_diff  >  1  flight  level)  THEN 
time  =  time  +  dtime_z 
TRACK.  alt_trend_time  =  dtime_z 

ELSE 

time  =  time  +  dtime_trans 

TRACK .  a  1 1_ t rend_ t i me  =  dtime_trans 

TRACK.  ZD  =  TRACK.  alt_trans_diff  /  time 

ELSE 

Trend  is  changing,  reset  its  velocity 
TRACK.  ZD  =  0 

TRACK.  alt_trend_time  =  0.2  *  scantime 
TRACK.  alt_state  =  GUESS 

TRACK. residual  =  0 

TRACK. alt _guess_time  =  (dtime_z  -  scantime)  *  atrans_diff  / 

(1  flight  level) 

No  processing  is  done  here  for  the  INITIALIZE  altitude  state  (it  should  never  be 
encountered  at  this  point  in  the  altitude  tracker  processing). 

C.5  Reset  Smoothing  State 

The  altitude  tracker  processing  is  performed  as  described  below  for  a  track  whose  altitude 
residual  has  grown  too  large  (indicating  a  missed  transition).  The  vertical  velocity  and  residual 
are  modified,  depending  on  whether  the  current  altitude  direction  (up,  down,  or  level)  is 
consistent  with  the  previous  altitude  update  for  this  track.  Setting  of  the  local  variables  was 
described  in  Section  C.l. 

IF  (t rans_sign  !=  TRACK.  alt_direct ion)  THEN 
Altitude  change  is  zero  or  other  direction,  reset  rate  towards 
zero 
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TRACK.  alt_state  =  TOZERO 
TRACK. residual  =  0 

TRACK. alt _trend_time  =  dtime_trans 
test_rate  =  1  flight  level  /  dtime_trans 
IF  (atrans_diff  >  1  flight  level)  THEN 

TRACK. ZD  =  0.1  *  test_rate  *  trans_sign  reset  the  vertical  rate 

ELSE 

Small  change  in  altitude  (less  than  1  flight  level) 

IF  (I  TRACK. ZD  I  •  test_rate)  THEN 
trate  =  0.6  *  test_rate  *  sign (TRACK. ZD) 

TRACK.  ZD  =  TRACK.  ZD  -  trate 

ELSE 

TRACK. ZD  =  0.4  *  TRACK. ZD 

ELSE 

Altitude  change  consistent  with  last  update,  reset  rate 

TRACK. alt_state  =  RESET 

TRACK. residual  =  0.15  *  TRACK . residual 

TRACK. alt_trend_time  =  dtime_trans  -  (0.2  *  scantime) 

test_rate  =  trans_rate  -  TRACK. ZD 

IF  ( I test_rate I  >  1.3  flight  levels  /  scantime)  THEN 
Alpha-Beta  smooth  the  vertical  velocity 
temp  =  (1  flight  level  *  sign (test_rate) ) 

TRACK. ZD  =  0.85  *  (TRACK . alt _trans_diff  -  temp)  /  dtime_z 

ELSE 

TRACK. ZD  =  (0.15  *  TRACK. ZD)  +  (0.85  *  trans  rate) 
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APPENDIX  D 

25  FOOT  ALTITUDE  TRACKER  ALGORITHM 


The  algorithm  described  here  to  track  aircraft  altitudes  quantized  in  25-foot  increments  was 
derived  from  the  “air  data”  function  of  ACAS  (see  [9]).  It  is  a  straightforward  alpha-beta 
technique  with  an  added  credibility  check  function.  This  algorithm  is  much  simpler  than  the  100- 
foot  altitude  tracker  algorithm  described  in  Appendix  C,  since  the  finer  altitude  quantization  does 
not  have  large  data  hops  over  short  measurement  intervals  (typically  one  Mode  S  radar  sensor 
scan  -  approximately  5  to  12  seconds).  The  parameters  incorporated  into  the  following  pseudo¬ 
code  were  determined  empirically. 

The  following  altitude  tracker  data  fields  are  assumed  for  each  aircraft  track: 

Z  tracked  altitude, 

ZD  tracked  altitude  rate, 

TDAT  time  of  most-recent  smoothing, 

TUPD  time  of  most-recent  altitude  data  input, 

CREDIBLE  flag  for  reasonable  altitude  data,  and 

SOFT  track’s  altitude  rigidity  value  (2..  10). 

At  each  surveillance  input,  the  tracker  is  called  with  Z1N  (25-foot  quantized  altitude)  and 
TIN  (time  of  ZIN  measurement).  For  the  first  update  on  a  given  track,  the  following 
initializations  are  performed. 

TRACK. Z  =  ZIN 
TRACK. ZD  =  0 
TRACK. TDAT  =  TIN 
TRACK. TUPD  =  TIN 

TRACK. SOFT  =  10  maximum  value  allowed 

TRACK. CREDIBLE  =  TRUE 

For  each  subsequent  surveillance  input,  the  following  algorithm  is  performed.  The  altitude 
predicted  for  the  current  time,  ZPRED,  is  checked  against  the  input  altitude  ZIN  for  credibility. 
If  it  is  a  credible  update  to  the  aircraft  track,  then  an  alpha-beta  smoothing  function  is  applied  to 
the  track’s  Z  and  ZD  values.  (Alpha  is  given  the  empirically  determined  value  of  0.58  and  beta 
is  given  the  value  of  0.25  in  this  example.)  The  track’s  softness  value  is  decreased  by 
one  (limited  to  a  minimum  value  of  2).  If  the  ZIN  value  for  this  altitude  update  is  not  considered 
credible,  then  the  track’s  altitude  is  reset  to  the  predicted  value  and  the  track’s  softness  increased 
by  one  (limited  to  a  maximum  value  of  10). 

ZDIFF  =  ZIN  -  ZPRED 

ZPRED  =  TRACK. Z  +  TRACK, ZD  *  (TIN  -  TRACK. TUPD) 

IF  ABS (  ZDIFF  )  • 35  feet  *  TRACK. SOFT  THEN 

Credible  altitude  alpha-beta  update  done  here 
TRACK. CREDIBLE  =  TRUE 
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TRACK. Z  =  ZPRED  +  (0.58  *  ZDIFF) 

TDIFF  =  TIN  -  TRACK. TDAT 

TRACK. ZD  =  TRACK. ZD  +  0.25  *  ZDIFF  /  TDIFF 
TRACK. TDAT  =  TIN 

TRACK. SOFT  =  Maximum (2,  TRACK. SOFT-1) 

ELSE 

Altitude  not  credible,  must  reset  tracker 
TRACK. Z  =  ZPD 

TRACK. SOFT  =  Minimum ( 10 , TRACK. SOFT+1 ) 
TRACK. credible  =  FALSE 
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APPENDIX  E 

NON-REAL-TIME  VERTICAL  POSITION  SMOOTHING  ALGORITHM 


The  vertical  tracker  algorithms  described  in  Appendix  C  (for  100-foot  flight  level  altitude 
inputs)  and  Appendix  D  (for  25-foot  quantized  altitude  inputs)  are  each  designed  for  application 
in  either  real-time  or  non-real-time  processing.  This  appendix  will  describe  a  vertical  position¬ 
smoothing  algorithm  specifically  developed  for  non  real-time  processing  of  recorded  radar 
surveillance  data.  Intended  for  the  analysis  of  ACAS  encounter  scenarios,  this  algorithm  takes  as 
its  input  an  array  of  altitudes  (denoted  z[])  and  their  corresponding  measurement  times  (denoted 
t[])  for  a  given  aircraft  track.  The  algorithm  description  here  assumes  that  these  arrays  arc 
indexed  from  1  through  N. 

The  first  step  of  this  algorithm  is  to  remove  any  invalid  altitude  values.  Mode  C  altitudes 
that  are  flagged  as  garbled  or  missing  are  removed  from  the  data  arrays.  (Note:  since  the  purpose 
of  vertical  position  smoothing  here  is  to  obtain  estimates  of  altitude  rate  in  order  to  check  values 
reported  in  the  aircraft’s  Mode  S  EHS  register  60t6,  only  altitudes  from  Mode  S-equipped  aircraft 
will  be  tracked  using  this  algorithm  here.  The  Mode  S  surveillance  protocols  utilize  error 
detection  and  correction  procedures  that  make  the  likelihood  of  missed  or  garbled  altitudes  very 
small.) 

The  second  step  of  the  non  real-time  vertical  tracker  algorithm  is  to  remove  any  outlier 
altitudes  from  the  data  set.  Such  outlier  altitudes  may  be  caused  by  undetected  bit  errors  in  the 
Mode  S  protocols,  errors  in  report-to-track  correlation,  or  by  problems  in  the  aircraft’s  avionics. 
These  outliers  appear  as  large  jumps  in  the  aircraft’s  altitude.  The  outlier  testing  begins  by 
computing  a  two-point  vertical  rate  for  each  data  point  1  through  N-l  using  the  following 
equation. 


z  ■  ,  —  z  . 
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If  the  magnitude  of  the  computed  vertical  rate  for  a  given  point  i  is  greater  than  5000  feet 
per  minute  (an  empirically-derived  parameter  larger  than  any  expected  vertical  rate  for  an  actual 
aircraft),  then  this  data  point  is  a  candidate  altitude  outlier.  The  candidate  outlier  point  whose 
vertical  rate  has  the  largest  magnitude  is  removed  from  the  data  set  and  the  vertical  rates  for  the 
remaining  points  are  computed.  (In  case  of  a  tie,  the  earliest-occurring  candidate  data  point  is 
removed.)  The  search  procedure  for  outlier  data  points  is  repeated  until  no  further  candidate 
outlier  points  are  found. 


The  third  step  of  the  non  real-time  vertical  position-smoothing  algorithm  is  to  perform  a 
smoothing  procedure  on  the  remaining  altitude  values  as  defined  in  the  following  equation: 


zsmooth .  = 


TMt'Jj) 
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The  weighting  function  co(tj,tj)  decreases  monotonically  as  the  difference  in  time  between  t( 
and  tj  increases.  The  following  equation  defines  the  weighting  function  selected.  It  is  a  Gaussian 
kernel  with  the  standard  deviation  parameter  a.  The  parameter  value  of  ct=15  seconds  was 
determined  empirically  (with  100-foot  flight  level  data). 

The  final  step  of  the  non  real-time  vertical  position-smoothing  algorithm  is  to  compute  the 
vertical  rate  for  each  of  the  remaining  data  points  using  the  same  two-point  equation  that  was 
used  for  outlier  detection,  except  that  the  smoothed  values  of  altitude  are  used  instead  of  the  input 
values.  Vertical  rate  values  can  be  computed  for  data  points  1  through  N-l. 
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APPENDIX  F 

RELATIONSHIPS  AMONG  GROUND  SPEED,  IAS,  TAS,  AND  MACH 


Aviation  systems  measure  speed  in  a  number  of  different  ways.  The  Mode  S  Enhanced 
Surveillance  (EHS)  application  provides  four  separate  speed  values  in  its  GICB  registers  (ground 
speed  and  true  airspeed  in  register  50|6,  indicated  airspeed  and  Mach  number  in  register  60, 6). 
This  Appendix  will  describe  each  of  these  different  speed  values  and  how  they  are  related.  The 
material  in  this  Appendix  was  derived  primarily  from  reference  [10]. 

The  most  straightforward  aircraft  speed  measurement  is  ground  speed.  This  speed  is 
determined  by  measuring  the  motion  of  the  aircraft  against  fixed  references  (either  on  the  Earth  or 
satellites).  The  aircraft  determines  ground  speed  via  GPS,  inertial  navigation,  VOR/DME,  or 
other  such  onboard  navigational  systems.  This  is  the  speed  that  a  ground  Mode  S  sensor  can 
determine  directly  from  tracked  positional  measurements,  so  its  value  can  be  directly  validated. 

Aircraft  also  measure  their  speed  with  respect  to  the  air  in  which  they  are  flying.  There  arc 
a  number  of  factors  that  make  this  speed  differ  from  the  aircraft’s  ground  speed.  First  of  all,  the 
air  moves  (wind)  -  and  the  aircraft  move  along  with  it. 

Therefore,  the  airspeed  is  calculated  as  the  vector  difference  of  the  ground  speed  and  the 
wind  speed: 


Airspeed  =  Groundspeed  -  Windspeed 

The  ground  Mode  S  sensor  has  no  way  to  measure  the  wind  field  at  the  location  of  the 
aircraft,  so  it  cannot  validate  airspeeds  directly  via  surveillance  data.  A  second  factor  is  that  the 
atmosphere  is  not  uniform  -  it  varies  as  a  function  of  altitude  and  temperature.  The  density  of  the 
atmosphere  drops  as  altitude  increases.  The  air  temperature  also  typically  drops  as  altitude 
increases.  The  aviation  standard  International  Standard  Atmosphere  (ISA)  assumes  a  sea  level 
temperature  of  59  degrees  F  /  15  degrees  C  and  a  lapse  rate  of  -3.57  degrees  F  /  2  degrees  C  per 
thousand  feet  of  altitude.  The  air  temperature  stabilizes  at  -69.7  degrees  F  /  -56.5  degrees  C  at 
about  36,000  feet.  The  air  temperature  then  remains  stable  up  to  about  65,000  feet.  The  ground 
Mode  S  sensor  has  no  way  to  measure  the  air  temperature  directly  -  it  must  be  inferred  from  the 
measured  barometric  altitude  reported  by  the  aircraft. 

There  are  several  types  of  airspeed  values  used  in  aviation.  These  are: 

Indicated  Airspeed  (IAS):  This  is  the  airspeed  shown  on  the  pilot’s  indicator.  This  is 
determined  onboard  by  measuring  the  air  pressure  produced  by  the  motion  of  the  aircraft  through 
the  air. 


Calibrated  Airspeed  (CAS):  This  is  the  IAS  corrected  for  errors  due  to  the  location  of 
the  airspeed  pressure  sensor(s)  of  the  aircraft.  Normally,  it  does  not  differ  significantly  from  IAS. 
For  purposes  of  this  appendix,  it  will  be  assumed  that  CAS  is  equivalent  to  IAS, 
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True  Airspeed  (TAS):  This  is  CAS  corrected  for  instrument  installation  errors, 
compressibility  errors,  and  errors  due  to  variations  from  standard  air  density  (effects  of  altitude 
and  temperature).  TAS  is  approximately  equal  to  CAS  at  sea  level  but  increases  relative  to  CAS 
as  altitude  increases.  For  example,  at  35,000  feet,  250  knots  CAS  is  approximately  430  knots 
TAS. 


Mach  Number  (M):  The  Mach  number  is  defined  to  be  the  ratio  of  the  speed  of  interest 
to  the  speed  of  sound  at  the  given  atmospheric  condition.  The  speed  of  sound  can  be  calculated 
in  units  of  TAS  as  a  function  of  aircraft  altitude  (up  to  36,000  feet)  using  the  standard 
International  Standard  Atmosphere  (ISA)  atmospheric  assumptions  (59  degrees  F  or  15  degrees  C 
at  sea  level  and  a  lapse  rate  of  -3.57  degrees  F  /  2  degrees  C  per  1000  feet)  via  the  following 
formula: 

Speed  of  Sound  (knots  TAS)  =  29.06  *  {  518.7  -  (3.57  *  A)  }0  5 

where  ‘A’  is  the  altitude  in  1000’s  of  feet.  At  36,000  feet,  the  speed  of  sound  is  573  knots.  At 
sea  level,  the  speed  of  sound  is  approximately  661.5  knots  assuming  ISA  conditions, 

Figures  F-l  and  F-2  illustrate  the  relationships  among  IAS/CAS,  TAS,  and  M  for  various 
altitudes  and  non-standard  temperature  conditions.  Figure  F-l  covers  the  lower  speed  range  (up 
to  1000  knots  TAS  -  subsonic  speeds)  and  Figure  F-2  covers  a  higher  speed  range  (600  to  1800 
knots  TAS  -  supersonic  speeds). 

An  example  case  for  the  use  of  these  relationships  is  illustrated  on  Figure  F-l .  Assume  that 
the  IAS  corrected  to  CAS  is  370  knots  (denoted  as  point  (A)  on  the  figure).  Assume  that  the 
aircraft  is  flying  at  25,000  feet  barometric.  Moving  horizontally  from  point  (A)  to  the 
intersection  with  the  line  indicating  the  aircraft’s  altitude  arrives  at  the  point  denoted  as  (B).  To 
find  the  value  of  M,  move  vertically  down  to  the  point  denoted  (C)  at  0.86  Mach.  To  get  the 
value  of  TAS  in  the  actual  environmental  conditions,  move  from  point  (B)  upwards  to  the 
intersection  with  the  sea  level  reference  line  (denoted  as  point  (D),  then  move  horizontally  to  the 
intersection  with  the  line  indicating  the  actual  air  temperature  (measured  in  Centigrade  units). 
The  example  assumes  a  non-standard  value  of  -20  degrees  C  -  denoted  point  (E)  on  the  figure. 
Moving  vertically  from  point  (E)  gets  the  TAS  for  this  case  (denoted  point  (F))  -  535  knots.  The 
dashed  lines  on  the  figure  illustrate  how  to  get  the  TAS  for  standard  atmospheric  conditions  -  515 
knots.  The  figure  can  also  be  used  in  reverse  to  derive  CAS  from  M  or  TAS. 
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Figure  F-l.  Relationships  Among  CAS,  TAS,  and  Mach  Numbers  for  Varying 
Temperature  and  Altitude  -  Subsonic. 
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Figure  F-2.  Relationships  Among  CAS,  TAS,  and  Mach  Numbers  for  Varying 
Temperature  and  Altitude  -  Supersonic. 
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CALIBRATED  AIRSPEED  -  KNOTS  CALIBRATED  AIRSPEED  -  KNOTS 


The  following  equations  relating  CAS,  TAS  and  Mach  number  were  taken  from 
reference  [11],  The  atmospheric  pressure  ratio  (at  actual  temperature  /  at  standard  temperature) 
as  a  function  of  the  aircraft  altitude  in  feet  (denoted  Lambda)  is  computed  as  follows  for  altitudes 
less  than  or  equal  to  36,000  feet  (the  pressure  ration  remains  constant  between  36,000  feet  and 
65,000  feet): 


Lambda  =  (1  -  0.0000068753  *  altitude)  5  2561 

The  following  procedure  computes  the  relationship  between  the  aircraft’s  CAS  (in  knots) 
and  its  Mach  number: 

T,  =  1  +0.2*  (CAS/ 661.5) 2 

T2  =  (T,)35-1 

T3  =  (1 /Lambda)  *  (T2+  1) 

T4  =  (T3)°-286  +  1 

Mach  =  (T4)° 5 

Note  that  the  speed  of  sound  in  ISA  conditions  at  sea  level  is  661.5  knots.  Defining  the 
atmospheric  temperature  ratio  (actual  temperature  /  standard  temperature)  as  theta  (temperatures 
in  degrees  Centigrade),  the  relationship  between  the  aircraft’s  Mach  number  and  its  TAS  (in 
knots)  is  given  by: 

TAS  =  661.5  *  Mach  *  (theta)0  5 

The  temperature  ration  can  be  modeled  using  the  ISA  standard  model  for  the  atmospheric 
temperature  lapse  rate  as  a  function  of  altitude  described  previously  in  this  appendix. 
Alternatively,  if  the  aircraft’s  measured  air  temperature  and  pressure  is  available  (see 
Appendix  G),  then  lambda  and  theta  can  be  calculated  directly. 
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APPENDIX  G 

THE  MODE  S  METEOROLOGICAL  AIR  REPORT  (REGISTER  4416) 


As  was  discussed  in  Appendix  F,  the  conversion  between  indicated  airspeed  and  true 
airspeed  involves  having  the  local  value  of  air  temperature.  While  this  value  can  be 
approximated  using  ISA  standard  day  rules,  it  would  be  better  to  have  the  actual  measured  value. 
Also,  the  full  validation  of  airspeed  and  heading  values  for  EHS  requires  having  the  local  wind 
speed  and  direction  data  from  the  aircraft’s  location.  The  wind  information  can  only  be  crudely 
approximated  with  Mode  S  ground  sensor  surveillance  data. 

While  it  is  not  a  part  of  the  ELS/EHS  application  definition  of  Mode  S,  a  transponder 
register  is  defined  (see  [2])  to  provide  aircraft-measured  meteorological  data.  As  shown  in  Figure 
G-l,  extraction  of  this  register  can  provide  the  values  of  wind  speed/direction  and  air  temperature 
required  to  validate  the  EHS  data.  Note:  if  the  input  surveillance  source  provides  ASTERIX 
Category  048  target  reports,  then  the  contents  of  the  extracted  register  44, 6  are  available  in  Data 
Item  250  as  described  in  Figure  1-2  of  this  report. 

The  following  configuration  tests  are  required  to  determine  if  the  aircraft’s  avionics  are 
supporting  the  meteorological  report  (register  44|6).  These  tests  are  in  addition  to  the  ELS/EHS 
configuration  tests  described  in  section  2  of  this  report: 

Bit  13  of  register  1 7 16  set  (see  Figure  A-2);  and 

Bit  45  of  register  19|6  set  (see  Figure  A-4). 

If  both  of  these  configuration  bits  are  set,  then  the  aircraft  supports  the  routine  meteorological 
report  (register  44|6). 

If  the  status  bit  for  winds  and  temperature  data  (bit  5)  of  register  44, 6  is  set,  then  the  wind 
speed  in  knots  (0...51 1)  is  extracted  from  bits  6  through  14.  The  wind  direction  in  degrees  with 
respect  to  geographic  north  (0... 360)  is  extracted  from  bits  15  through  23.  The  LSB  for  wind 
direction  is  360/29,  about  0.7  degrees.  Note  that  the  wind  direction  in  register  44!6  is  an  unsigned 
vale  measured  clockwise  from  north  -  not  a  signed  value  like  the  EHS  true  track  angle  (in  register 
50|6)  and  magnetic  heading  (in  register  60|6).  The  airspeed  is  computed  as  the  vector  sum  of  the 
ground  speed  (measured  via  the  surveillance  radar)  and  the  wind  speed  extracted  from  the 
meteorological  data.  The  air  temperature  in  degrees  C  (-128.  ..+128)  is  extracted  from  register 
44 ,6  as  follows: 

( 1 )  Extract  bit  24  as  SIGN 

(2)  Extract  bits  25  through  34  as  VAL 

(3)  IfSIGN=l,  then  VAL  =  VAL- 210 

(4)  Air  Temperature  (degrees  C)  =  VAL  /  2 10 
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The  LSB  of  the  extracted  temperature  data  is  0.25  degrees  C.  It  should  be  noted  that  the  aircraft 
actually  computes  the  wind  data  onboard  by  comparing  its  source  of  navigation  data  (e.g.,  GPS, 
INS)  with  its  source  of  air-relative  data  (airspeed  and  heading). 

MB  FIELD 


1 

2 

RESERVED 

3 

4 

5 

STATUS 

6 

MSB  -  256  knots 

7 

8 

9 

WIND  SPEED 

10 

1 1 

Range  [0,511]  knots 

12 

13 

14 

I. SB  1  knot 

15 

STATUS 

16 

MSB  -  180  degrees 

17 

18 

WIND  DIRECTION  (True) 

19 

20 

Range  =  [0,  360]  degrees 

21 

22 

23 

I .SB  ~  1 80/ 1 28  degrees 

24 

STATUS 

25 

SIGN 

26 

MSB  -  64"C 

27 

28 

29 

STATIC  AIR  TEMPERATURE 

30 

31 

Range -[-128,  *1281°C 

32 

33 

34 

35 

LSB  0.125"  C 

36 

STATUS 

37 

MSB  -  1  024  hPa 

38 

39 

40 

AVERAGE  STATIC  PRESSURE 

41 

42 

Range  -  [0.  2  047]  hPa 

43 

44 

45 

46 

47 

LSB  =  1  hPa 

48 

TURBULENCE  FLAG 

49 

STATUS 

50 

MSB  *  64% 

51 

52 

53 

HUMIDITY 

54 

Range  -  (0,  127J  % 

55 

56 

I  .SB  -  1  % 

PURPOSE:  To  allow  meteorological  data  to  be  collected  by 
ground  systems. 


I )  The  definition  of  hit  48  Turbulence  flag 

0  *  signifies  turbulence  data  not  available  in  Register  45, fc. 

1  =  signifies  turbulence  data  available  in  Register  45 ih. 

Mote  /  The  average  static  pressure  is  not  a  requirement  of 
Annex  3. 

Mote  2.  Humidity  calculation  may  result  in  values  greater  than  100  % 

Mote  J.  Two  \s  complement  coding  is  used  for  all  signed  fields  as 
specified  in  $A.2.2.2. 

Mote  4.  -  The  requirement  for  the  range  of  wind  speeds  in  Annex  3 
is  from  0  to  250  knots. 

Mote  5.  -  The  requirement  for  the  range  of  static  air  temperature  in 
Annex  3  is  from  -80"  C  to  +  60"  C. 


Figure  G-l.  Routine  Meteorological  Report  (BDS  Code  4,4). 
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APPENDIX  H 

THE  FAA’S  TERMINAL  MODE  S  SENSOR  COMMUNICATIONS 

INTERFACE  DESIGN 


The  Mode  S  sensors  specified  in  [6]  and  fielded  by  the  FAA  in  terminal  areas  across  the 
U.S.  do  not  support  the  ASTERIX  formats  (specified  in  [5]).  Instead,  these  sensors  employ  a 
combination  of  the  Common  Digitizer  (CD-2)  surveillance  output  specified  in  [14]  and  the 
communications  interface  specified  in  [13].  This  Appendix  will  discuss  the  techniques  and 
methods  required  to  employ  these  sensors  for  ELS  and  EHS  validation. 

The  FAA’s  terminal  Mode  S  sensors  provide  their  surveillance  output  to  ATC  applications 
using  the  CD-2  format.  While  this  surveillance  output  is  sufficient  to  drive  controller’s  displays, 
it  lacks  several  key  data  items  necessary  for  ELS/EHS  validation.  In  particular,  CD-2  format 
does  not  provide  the  Mode  S  address  for  Mode  S-equipped  aircraft.  Even  if  the  address  for  the 
desired  aircraft  is  known  prior  to  testing,  there  is  no  direct  way  to  match  the  CD-2  surveillance 
data  with  the  address.  CD-2  data  does  not  provide  a  track  number  either.  The  aircraft’s  Mode 
3/A  (ATCRBS)  code  is  the  only  means  to  locate  a  particular  aircraft  in  the  CD-2  data  stream  - 
assuming  that  the  aircraft  has  been  assigned  a  discrete  (known)  Mode  3/A  code.  Unlike 
ASTERIX  format,  CD-2  provides  no  mechanism  for  transmitting  the  contents  of  Mode  S 
transponder  registers.  Hence,  the  CD-2  surveillance  data  stream  is  not  useful  for  ELS/EHS 
validation  application. 

The  FAA’s  terminal  Mode  S  sensor  communications  interface,  however,  can  provide  the 
necessary  surveillance  data  items  and  control  functions  for  ELS/EHS  validation.  This 
Appendix  will  discuss  the  subset  of  the  communications  interface  functionality  used  for  this 
application.  The  material  in  this  Appendix  is  derived  from  [13]. 

H.l  Link-Level  Protocols 

The  Mode  S  communications  interface  operates  over  a  point-to-point,  bidirectional, 
synchronous,  bit-serial  link  layer  as  specified  in  the  CC1TT  X.25  LAPB  standard  ([15]).  The 
Mode  S  sensor  operates  as  a  Data  Terminal  Equipment  (DTE)  port  under  the  X.25  protocol.  A 
single  sensor  can  handle  multiple  communication  interfaces;  each  communications  interface  may 
be  separately  configured.  The  ELS/EHS  validation  application  operates  as  an  X.25  Data  Circuit 
Terminating  Equipment  (DCE). 

Each  Mode  S  message  is  transferred  in  an  X.25  data  frame.  Each  frame  starts  and  ends 
with  a  flag  sequence.  Addressing  and  control  information  in  the  frame  header  specify  the  source 
and  destination  of  each  frame,  as  well  as  whether  the  frame  contains  user  data  or  link  control 
functions.  Frame  numbering  in  the  control  information  provides  for  detection  of  out-of-sequence 
or  lost  frames.  Each  frame  incorporates  a  frame-check  sequence  that  is  used  to  detect  frames 
containing  bit  errors.  A  zero-insertion  algorithm  is  used  to  provide  unambiguous  detection  of  the 
flag  sequences.  Exception  and  recovery  processing  is  defined  by  the  X.25  standard  to  deal  with 
the  various  link-level  error  conditions.  As  implemented  in  Mode  S,  the  largest  data  frame 
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contains  1024  bytes.  (The  longest  data  frame  of  the  subset  of  messages  to  be  used  for  ELS/EHS 
validation  is  only  22  bytes.) 

H.2  Communications  Interface  Messages 

An  FAA  terminal  sensor  can  support  multiple  communications  interfaces.  (Note:  none  of 
these  interfaces  are  currently  connected  in  the  NAS.)  Each  communications  interface  may  be 
operated  in  one  of  two  modes  as  selected  by  a  sensor  configuration  parameter.  If  the  user  of  the 
communications  interface  is  a  normal  ATC  facility  also  receiving  surveillance  data  via  the  CD-2 
interface,  then  the  communications  interface  is  operated  in  the  ATC  mode.  However,  as 
discussed  above  in  this  appendix,  CD-2  surveillance  data  is  not  appropriate  for  the  ELS/EHS 
validation  task.  For  ELS/EHS  validation,  the  communications  interface  should  be  operated  in  the 
non-ATC  mode.  As  will  be  discussed  below,  this  mode  provides  for  both  surveillance  (of 
Mode  S-equipped  aircraft  only)  and  communications  data  (e.g.,  the  extraction  of  GICB  registers 
from  an  aircraft  equipped  with  a  Mode  S  transponder)  to  share  the  single  interface  with  the 
sensor.  The  surveillance  data  available  in  the  non-ATC  mode  does  contain  the  data  items 
required  for  ELS/EHS  validation.  The  remainder  of  this  appendix  will  only  consider  those 
messages  and  protocols  supported  by  the  non-ATC  mode  of  the  communications  interface. 

H.2.1  Common  Data  Fields  in  non-ATC  Communications  Messages 

This  section  will  describe  the  commonly  used  data  items  in  non-ATC  mode  messages 
employed  over  the  Mode  S  communications  interface.  Data  items  particular  to  a  specific 
message  will  be  described  with  the  message  itself. 

H.2. 1. 1  Sensor  Identifier 

The  sensor  identifier  is  a  10-bit  number  that  uniquely  specifies  the  sensor  generating  the 
message.  This  functionality  was  added  to  permit  multi-sensor  networking,  and  it  is  not  required 
for  any  currently  fielded  application. 

H.2. 1. 2  Message  Number 

Each  message  over  the  communications  interface  is  given  a  unique  8-bit  identifying 
number.  Messages  output  from  the  sensor  to  the  user  (e.g.,  ELS/EHS  validation)  use  the  range  of 
numbers  129  through  255,  while  messages  received  by  the  sensor  from  the  user  use  the  range  of 
numbers  1  through  127.  Message  numbers  0  and  128  are  reserved.  The  message  number  128  is 
typically  used  for  broadcast  messages.  The  message  numbers  are  used  to  match  user  data 
requests  with  sensor  responses.  The  numbers  should  be  assigned  sequentially  at  each  end  of  the 
communications  interface  (from  the  appropriate  range  of  numbers).  Up  to  1 27  outstanding 
messages  in  each  direction  can  be  handled  by  the  communications  interface  protocol. 

H.2. 1.3  Padding  Bits 

In  order  to  align  certain  fields  of  the  message  on  byte  boundaries  for  coding  efficiency,  the 
message  formats  sometimes  employ  padding  bits.  These  bits  are  always  cleared  to  zero. 
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H.2.1.4  Type  Code 


The  first  byte  of  each  communications  interface  message  is  a  type  code  that  identifies  the 
particular  message.  Table  H-l  defines  the  subset  of  non-ATC  mode  message  type  codes  used  for 
ELS/EHS  validation.  The  term  downlink  in  this  table  refers  to  messages  (responses)  coming 
from  the  aircraft  through  the  sensor  interface  to  the  user  (e.g.,  ELS/EHS  validation).  The  term 
uplink  refers  to  messages  (requests)  coming  from  the  user  through  the  sensor  interface  and  sent 
up  to  the  aircraft.  The  type  code  values  are  expressed  in  hexadecimal  notation. 


Table  H-1 

Non-ATC  Message  Type  Codes  (subset  for  ELS/EHS) 


Category 

Type  Code 

Message  Type 

Sensor  Error 
Response 

31,6 

Message  Rejection/Delay  Notice 

Downlink 

34l6 

Data  Link  Capability  Response 

40,6 

Broadcast  Downlink 

44I6 

GICB  Downlink  Response 

45,6 

ATCRBS  Mode  3/A  Code  Response 

48,6 

Broadcast  Downlink  with  Position 

4C,6 

GICB  Downlink  Response  with  Position 

4F,6 

Aircraft  Position  Response 

Uplink 

09,6 

Aircraft  Position  Request 

0Ai6 

Data  Link  Capability  Request 

24,  „ 

ATCRBS  Mode  3/A  Code  Request 

2B,6 

GICB  Downlink  Request 

Sensor  Status 

4B,6 

Track  Drop  Message 

H.2.2  Request-Response  Messages 

Most  of  the  non-ATC  messages  on  the  communications  interface  follow  a  request-response 
protocol  -  the  user  sends  a  request  message  to  the  Mode  S  sensor  asking  for  a  particular  item  of 
aircraft  data  from  a  specific  aircraft.  Some  time  later,  the  sensor  responds  with  a  message 
containing  the  requested  data.  The  set  of  request-response  message  pairs  used  by  the  ELS/EHS 
validation  function  will  be  described  below.  (Note:  the  broadcast  downlink  message 
with/without  position  (Section  H.2.2. 5)  is  not  elicited  by  a  user  request.  The  Data  Link 
Capability  Response  message  (Section  H.2.2. 2)  is  also  generated  without  requiring  a  user  request 
when  an  aircraft  is  newly-acquired  by  a  Mode  S  sensor.) 

If  the  sensor  cannot  fulfill  the  user’s  request  (e.g.,  aircraft  not  in  sensor’s  database,  request 
message  format  incorrect),  then  a  message  rejection/delay  message  is  sent  instead  of  the  expected 
response.  Table  H-2  illustrates  the  format  of  this  error  status  message. 
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Table  H-2 

Format  of  Message  Rejection/Delay  Notice 


Data  Field 

Number  of  Bits 

Commentary 

Type  Code 

8 

31,6 

Mode  S  Address 

24 

Address  from  request 

Message  Number 

8 

Number  from  request 

Qualifier 

3 

0  =  target  not  in  data  base, 

1=  target  not  yet  in  roll-call, 

2  =  too  many  messages, 

3  =  sensor  not  primary, 

4  =  no  ELM  support, 

5. .7  unassigned 

Padding  Bits 

3 

000 

Sensor  Identifier 

10 

Supporting  Sensor 

H.2.2.1  ATCRBS Mode  3/A  Request-Response 

The  format  for  the  ATCRBS  Mode  3/A  request  message  is  illustrated  in  Table  H-3(A). 
(Note:  this  data  can  only  be  obtained  for  Mode  S-equipped  aircraft  in  the  sensor’s  coverage.) 
The  format  for  the  matching  response  message  is  illustrated  in  Table  H-3(B).  The  ATCRBS 
Mode  3/A  code  consists  of  12  bits  expressed  as  4  octal  digits. 

Table  H-3(a) 


Format  of  ATCRBS  Mode  3/A  Req 

uest  Message 

Data  Field 

Number  of  Bits 

Commentary 

Type  Code 

8 

24i6 

Mode  S  Address 

24 

Request  Address 

Message  Number 

8 

Request  Message  Number 

Table  H-3(b) 

Format  of  ATCRBS  Mode  3/A  Response  Message. 


Data  Field 

Number  of  Bits 

Commentary 

Type  Code 

8 

45,6 

Mode  S  Address 

24 

Address  from  Request 

Message  Number 

8 

Response  Message  Number 

Padding  Bits 

4 

0000 

ATCRBS  Mode  3/A  Code 

12 

4  octal  digits 

Padding  Bits 

6 

000000 

Sensor  Identifier 

10 

Supporting  Sensor 

H.2.2.2  Data  Link  Capability  Request-Response 

The  format  for  the  Data  Link  Capability  request  message  is  illustrated  in  Table  H-4(A). 
The  format  for  the  matching  response  message  is  illustrated  in  Table  H-4(B).  (Note:  this  data 
can  only  be  obtained  for  Mode  S-equipped  aircraft  in  the  sensor’s  coverage.)  The  Data  Link 
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Capability  response  returns  the  3-bit  value  of  the  aircraft  transponder’s  CA  field  (see  Section  2. 1 ). 
It  also  returns  the  low-order  52  bits  of  the  aircraft’s  data  link  capability  register  (10i6)  contents 
termed  the  extended  capability  (see  A-l  for  the  format  of  this  register).  The  first  4  bits  of  the 
register  contents  are  a  constant  value,  so  nothing  is  lost  by  omitting  them.  For  ELS/EHS  testing, 
the  first  four  bits  of  the  capability  data  should  be  reset  to  the  value  1 . 


Table  H-4(a) 

Format  of  Data  Link  Capability  Request  Message 


Data  Field 

Number  of  Bits 

Commentary 

Type  Code 

8 

0A|6 

Mode  S  Address 

24 

Request  Address 

Message  Number 

8 

Request  Message  Number 

Table  H-4(b) 


Format  of  Data  Link  Capability  Response  Message 


Data  Field 

Number  of  Bits 

Commentary 

Type  Code 

8 

34l6 

Mode  S  Address 

24 

Address  from  Request 

Message  Number 

8 

Response  Message  Number 

Padding  Bit 

1 

0 

Transponder  CA  Value 

3 

See  section  2.1 

Transponder  Extended 
Capability  Value 

52 

Low-order  52  bits  of 
transponder  register  10|6 

Padding  Bits 

6 

000000 

Sensor  Identifier 

10 

Supporting  Sensor 

H.2.2.3  Aircraft  Position  Request-Response 

The  format  for  the  Aircraft  Position  request  message  is  illustrated  in  Table  H-5(A).  (Note: 
position  data  can  only  be  obtained  for  Mode  S-equipped  aircraft  in  the  sensor’s  coverage.)  The 
format  for  the  matching  response  message  is  illustrated  in  Table  H-5(B).  The  response  message 
contains  the  aircraft’s  position  (range,  azimuth,  altitude)  as  well  as  the  horizontal  velocity 
components  (range-rate,  azimuth-rate).  Note  that  the  LSBs  for  the  range  and  azimuth  position 
values  are  larger  than  the  raw  sensor  -  the  measurement  sigma  values  need  to  be  adjusted 
accordingly.  The  velocity  values  in  the  response  message  are  computed  using  a  2-point 
interpolator,  so  they  are  likely  to  be  quite  noisy  and  some  form  of  smoothing  algorithm  should  be 
used  before  applying  these  velocity  values  for  ELS/EHS  validation  purposes.  Also,  note  that 
terminal  sensors  are  typically  calibrated  in  azimuth  with  respect  to  magnetic  north  at  the  sensor. 


Table  H-5(a) 

Format  of  Aircraft  Position  Request  Message 


Data  Field 

Number  of  Bits 

Commentary 

Type  Code 

8 

09)6 

Mode  S  Address 

24 

Request  Address 

Message  Number 

8 

Request  Message  Number 
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Table  H-5(b) 

Format  of  Aircraft  Position  Response  Message 


Data  Field 

Number  of  Bits 

Commentary 

Type  Code 

8 

4FI6 

Mode  S  Address 

24 

Address  from  Request 

Message  Number 

8 

Response  Message  Number 

Padding  Bits 

2 

00 

Range 

10 

0..255  nautical  miles, 

LSB=l/4  mile 

Azimuth 

12 

0..360  degrees, 

LSB=360/212  (-0.088  deg.) 

Padding  Bits 

2 

00 

Range  Rate 

6 

Nautical  miles/second, 

LSB=0.0125  (-45  knots), 

MSB=0.2  (-720  knots) 

Azimuth  Rate 

8 

Degrees/second, 

LSB=0.031,  MSB=2 

Aircraft  State 

4 

0=aircraft  not  in  sensor  data  base, 
l=aircraft  not  in  roll-call  yet, 

2=full  track,  sensor  controlled 
primary, 

3=full  track,  controlled  secondary, 
4=full  track,  uncontrolled  primary, 
5=full  track,  uncontrolled  secondary, 
6..  15  unassigned 

NOTE:  values  2. .5  are  equivalent  for 
ELS/EHS  validation 

Altitude 

12 

Mode  C  altitude  of  aircraft  in  Gray 
code  bits  (Q  bit  determines  100-foot 
or  25-foot  encoding) 

Padding  Bits 

6 

000000 

Sensor  Identifier 

10 

Supporting  Sensor 

H.2.2.4  GICB  Downlink  Request-Response 

The  format  for  the  GICB  Downlink  request  message  is  illustrated  in  Table  H-6(A).  The 
format  for  the  matching  response  message  is  illustrated  in  Table  H-6(B).  A  new  request  is 
required  for  each  transponder  register  extraction  desired. 

A  priority  value  from  0  (lowest  priority)  to  15  (highest  priority)  is  included  in  the  request 
message.  If  there  is  a  queue  of  messages  waiting  for  a  particular  aircraft,  the  messages  will  be 
sent  in  priority  order.  The  only  Mode  S  data  link  application  currently  operating  in  terminal 
sensors,  TIS,  uses  priority  10.  Hence,  a  lower  priority  is  suggested  for  ELS/EHS  validation 
requests  in  order  to  avoid  conflicting  with  the  TIS  application. 
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Each  request  is  given  a  maximum  number  of  sensor  scans  in  which  to  complete  (before  a 
rejection  notice  will  be  sent  to  the  user).  The  coding  of  the  expiration  value  is  given  in  the  table 
H-6(B)  commentary.  To  avoid  overloading  the  sensor,  an  expiration  value  of  no  more  than  2 
scans  is  recommended. 


Table  H-6(a) 

Format  of  GICB  Downlink  Request  Message 


Data  Field 

Number  of  Bits 

Commentary 

Type  Code 

8 

2BI6 

Mode  S  Address 

24 

Request  Address 

Message  Number 

8 

Request  Message  Number 

Priority 

4 

Suggested  value=8 

Expiration 

3 

0=1  scan, 

7=no  expiration, 

1..6=  2(exp  l)  scans 

Padding  Bit 

1 

0 

Register  BDS  Code 

8 

Desired  Transponder 

Register 

Table  H-6(b) 

Format  of  GICB  Downlink  Response  Message 


Data  Field 

Number  of  Bits 

Commentary 

Type  Code 

8 

44|6 

Mode  S  Address 

24 

Address  from  Request 

Message  Number 

8 

Response  Message  Number 

Register  BDS  Code 

8 

Requested  transponder  register 

Register  Contents 

56 

Extracted  Register  Contents 

Padding  Bits 

6 

000000 

Sensor  Identifier 

10 

Supporting  Sensor 

It  should  be  noted  that  a  GICB  Downlink  response  message  can  be  combined  with  an 
Aircraft  Position  response  if  the  sensor’s  communication  interface  configuration  parameters  for 
this  port  are  set  up  for  this  function.  (Note:  position  data  can  only  be  obtained  for  Mode  S- 
equipped  aircraft  in  the  sensor’s  coverage.)  There  is  a  trade-off  between  the  extra  bits  required 
on  the  communications  link  (since  every  GICB  downlink  and  broadcast  downlink  message  will 
have  the  extra  position  fields  appended)  versus  not  requiring  a  separate  aircraft  position  request 
message  for  each  aircraft  (and  potential  positional  latency  issues).  Table  H-6(C)  illustrates  the 
format  of  the  GICB  Downlink  with  Position  Response  Message. 
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Table  H-6(c) 

Format  of  GICB  Downlink  with  Position  Response  Message 


Data  Field 

Number  of  Bits 

Commentary 

Type  Code 

8 

4C|6 

Mode  S  Address 

24 

Address  from  Request 

Message  Number 

8 

Response  Message  Number 

Register  BDS  Code 

8 

Requested  transponder  register 

Register  Contents 

56 

Extracted  Register  Contents 

Padding  Bits 

2 

00 

Range 

10 

0..255  nautical  miles, 

LSB=l/4  mile 

Azimuth 

12 

0..360  degrees, 

LSB=360/212  (-0.088  deg.) 

Padding  Bits 

2 

00 

Range  Rate 

6 

Nautical  miles/second, 

LSB=0.0125  (—45  knots), 

MSB=0.2  (-720  knots) 

Azimuth  Rate 

8 

Degrees/second, 

LSB=0.031,  MSB=2 

Aircraft  State 

4 

0=aircraft  not  in  sensor  database, 
l=aircraft  not  in  roll-call  yet, 

2=full  track,  controlled  primary, 
3=full  track,  controlled  secondary, 
4=full  track,  uncontrolled  primary, 
5=full  track,  uncontrolled 
secondary, 

6..  15  unassigned 

NOTE:  values  2. .5  are  equivalent  for 

ELS/EHS  validation 

Altitude 

12 

Mode  C  altitude  of  aircraft  in  Gray 
code  bits  (Q  bit  determines  100- 
foot  or  25-foot  encoding) 

Padding  Bits 

6 

000000 

Sensor  Identifier 

10 

Supporting  Sensor 

H.2.2.5  Broadcast  Downlink 

The  format  for  the  Broadcast  Downlink  message  is  illustrated  in  Table  H-7(A).  These 
messages  result  from  transponder  broadcasts  and  are  not  the  result  of  a  request  message.  Note 
that  the  first  8  bits  of  the  broadcast  data  contain  the  register  identifier  (BDS  code). 


108 


Table  H-7(a) 

Format  of  Broadcast  Downlink  Message 


Data  Field 

Number  of  Bits 

Commentary 

Type  Code 

8 

40l6 

Mode  S  Address 

24 

Address  from  Request 

Message  Number 

8 

Message  Number  =  1 28 

Register  Contents 

56 

Broadcast  Register  Contents 

Padding  Bits 

6 

000000 

Sensor  Identifier 

10 

Supporting  Sensor 

It  should  be  noted  that  a  Broadcast  Downlink  message  can  be  combined  with  an  Aircraft 
Position  response  if  the  sensor  communications  interface  configuration  parameters  for  this  port 
are  set  up  for  this  function.  (Note:  position  data  can  only  be  obtained  for  Mode  S-equipped 
aircraft  in  the  sensor’s  coverage.)  There  is  a  trade-off  between  the  extra  bits  required  on  the 
communications  link  (since  every  GICB  downlink  and  broadcast  downlink  message  will  have  the 
extra  position  fields  appended)  versus  not  requiring  a  separate  aircraft  position  request  message 
for  each  aircraft  (and  potential  positional  latency  issues).  Table  H-7(B)  illustrates  the  format  of 
the  GICB  Downlink  with  Position  Response  Message. 


109 


Table  H-7(b) 

Format  of  Broadcast  Downlink  with  Position  Response  Message 


Data  Field 

Number  of  Bits 

Commentary 

Type  Code 

8 

4816 

Mode  S  Address 

24 

Address  from  Request 

Message  Number 

8 

Message  Number  =  128 

Register  Contents 

56 

Extracted  Register  Contents 

Padding  Bits 

6 

000000 

Range 

10 

0..255  nautical  miles, 

LSB=l/4  mile 

Azimuth 

12 

0..360  degrees, 

LSB=360/212  (-0.088  deg.) 

Padding  Bits 

2 

00 

Range  Rate 

6 

Nautical  miles/second, 

LSB=0.0125  (-45  knots), 

MSB=0.2  (-720  knots) 

Azimuth  Rate 

8 

Degrees/second, 

LSB=0.031,  MSB=2 

Aircraft  State 

4 

0=aircraft  not  in  sensor  database, 
l=aircraft  not  in  roll-call  yet, 

2=full  track,  controlled  primary, 
3=full  track,  controlled  secondary, 
4=full  track,  uncontrolled  primary, 
5=full  track,  uncontrolled 
secondary, 

6..  15  unassigned 

NOTE:  values  2. .5  are  equivalent  for 

ELS/EHS  validation 

Altitude 

12 

Mode  C  altitude  of  aircraft  in  Gray 
code  bits 

Padding  Bits 

6 

000000 

Sensor  Identifier 

10 

Supporting  Sensor 

H.2.2.6  Determination  of  Mode  S  Addresses 

To  this  point,  the  discussion  of  the  Mode  S  communications  interface  protocols  has 
assumed  that  the  user’s  application  knows  the  aircraft’s  Mode  S  address  prior  to  making  any  data 
requests  to  it.  This  section  will  describe  the  process  by  which  the  user’s  application  (e.g., 
ELS/EHS  validation)  determines  the  Mode  S  addresses  of  the  aircraft  currently  in  coverage  of  the 
Mode  S  sensor  supporting  the  interface. 

Whenever  a  new  Mode  S-equipped  aircraft  is  acquired  by  the  sensor  and  placed  under  roll- 
call  track,  a  Data  Link  Capability  Response  message  (see  Table  H-4(B))  is  spontaneously 
transmitted  (without  requiring  a  request  input)  from  the  sensor  on  the  communications  interface. 
The  message  number  for  this  message  will  be  128  -  the  default  value.  The  user’s  application 
should  monitor  these  messages,  adding  the  Mode  S  address  from  these  messages  to  its  list  of 
aircraft  available  for  subsequent  data  requests. 
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The  Mode  S  communications  interface  protocol  will  attempt  to  deliver  messages  to  an 
aircraft  regardless  of  whether  the  aircraft  is  properly  equipped  to  respond  to  them.  These 
unanswered  uplinks  interfere  with  the  operation  of  the  sensor  and  should  be  avoided.  Hence,  the 
user  application  should  check  the  aircraft’s  Mode  S  data  link  capabilities  prior  to  requesting  any 
data  other  than  the  ATCRBS  Mode  3/A  code  (H. 2. 2.1)  or  the  Aircraft  Position  (H. 2. 2. 3).  In 
particular,  the  GICB  Downlink  Request  message  (H.2.2.4)  should  not  be  generated  for  an  aircraft 
whose  Mode  S  transponder  CA  value  is  less  than  4. 

The  Mode  S  sensor  generates  a  Track  Drop  message  on  the  communications  interface  to 
indicate  that  a  particular  aircraft  has  left  sensor  coverage.  Table  H-8  illustrates  the  format  of  the 
Track  Drop  Message.  The  message  includes  the  sensor  identifiers  for  two  adjacent 
sensors  (secondary  and  tertiary)  as  well  as  the  supporting  sensor.  This  mechanism  was  intended 
to  support  sensor  networking,  but  is  not  operational  in  the  FAA’s  fielded  Mode  S  sensors. 


Table  H-8 

Format  of  Track  Drop  Message 


Data  Field 

Number  of  Bits 

Commentary 

Type  Code 

8 

4B|6 

Mode  S  Address 

24 

Address  from  Request 

Message  Number 

8 

Message  Number 

Padding  Bits 

6 

000000 

Sensor  Identifier 

10 

Secondary  sensor 

Padding  Bits 

6 

000000 

Sensor  Identifier 

10 

Tertiary  sensor 

Padding  Bits 

6 

000000 

Sensor  Identifier 

10 

Supporting  Sensor 
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APPENDIX  I 

THE  ASTERIX  CATEGORY  018  SURVEILLANCE  AND 
DATA  LINK  INTERFACE 


The  ASTERIX  Category  018  interface  function  provides  bi-directional  surveillance  and 
Mode  S  data  link  communications  between  Mode  S  sensors  and  applications  such  as  ELS/EHS 
monitoring  and  validation.  ASTERIX  Category  018  provides  an  internationally  standardized 
equivalent  functionality  to  the  FAA’s  communications  interface  that  was  described  in  Appendix 

H.  This  appendix  will  describe  the  subset  of  ASTERIX  Category  018  functionality  that  would  be 
used  for  ELS/EHS  monitoring  and  validation  applications.  See  [16]  for  the  complete  definition 
of  ASTERIX  Category  018  formats  and  protocols. 

I. 1  Common  Data  Items 

All  the  ASTERIX  Category  018  messages  used  for  ELS/EHS  monitoring  and  validation 
applications  have  four  common  data  items.  These  data  items  common  to  all  messages  will  be 
described  in  this  section.  Those  data  items  specific  to  a  given  message  type  will  be  described 
with  that  particular  message.  A  summary  of  all  the  ASTERIX  Category  018  Data  Items 
described  in  this  appendix  is  given  in  Table  1-7  (see  Section  1.5). 

1.1.1  Message  Type 

The  Message  Type  (Data  Item  000)  is  a  one-byte  value  that  identifies  the  type  of  the 
ASTERIX  Category  018  message.  Table  1-1  defines  the  message  type  encodings  used  for  the 
subset  of  ASTERIX  Category  018  messages  used  for  ELS/EHS  monitoring  and  validation 
applications.  The  message  type  coding  values  in  Table  1-1  are  given  in  hexadecimal  notation. 
See  [15]  for  the  complete  list  of  ASTERIX  Category  018  message  type  values. 


Table  1-1 

ASTERIX  Category  018  Message  Type  Encodings 


Message  Type 

Encoding 

Section  Reference 

Request  Aircraft  Report 

1  1 16 

H.2.1 

Aircraft  Report  Response 

10,6 

H.2.2 

Request  GICB  Extraction 

40,6 

H.3.1 

GICB  Extraction  Response 

43,6 

H.3.2 

GICB  Extraction  Acknowledgement 

42,6 

H.3.3 

Cancel  GICB  Extraction 

41,6 

H.3.4 

Downlink  Broadcast 

34,6 

H.4 

1.1.2  ModeS  Address 

The  Mode  S  Address  (Data  Item  005)  contains  the  address  of  the  aircraft  that  is  the  source 
of,  or  the  destination  for,  this  particular  message.  The  address  field  consists  of  3  bytes  (24  bits). 
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1.1.3  Data  Source  Identifier 


The  data  source  identifier  (Data  Item  036)  provides  the  identification  of  the  message 
source.  For  uplinks,  this  would  be  the  identification  of  the  ELS/EHS  monitor.  For  downlinks, 
this  would  be  the  identification  of  the  Mode  S  sensor  supporting  the  ELS/EHS  monitoring  and 
validation  application. 

The  data  source  identifier  consists  of  two  bytes.  The  high-order  byte  is  the  system  area 
code  (SAC)  that  denotes  that  geographic  region  in  which  the  data  source  resides.  (See  [17]  for 
the  standard  SAC  encodings.)  The  low-order  byte  is  the  system  identity  code  (SIC)  that  specifies 
the  particular  system  within  the  geographic  region.  SIC  values  are  defined  by  the  agency  that 
controls  the  geographic  region  of  the  particular  SAC  value. 

1.1.4  Data  Destination  Identifier 

The  data  destination  identifier  (Data  Item  037)  provides  the  identification  of  the  message 
destination.  For  downlinks,  this  would  be  the  identification  of  the  ELS/EHS  monitor.  For 
uplinks,  this  would  be  the  identification  of  the  Mode  S  sensor  supporting  the  ELS/EHS 
monitoring  and  validation  application. 

The  data  destination  identifier  consists  of  two  bytes.  The  encoding  of  the  data  destination 
identifier  is  generated  in  an  equivalent  manner  to  the  data  source  identifier  described  in  1.1.3  (one 
byte  SAC  and  one  byte  SIC). 

1.2  Aircraft  Report  (Surveillance  Data) 

ASTERIX  Category  018  provides  a  request-response  protocol  that  allows  an  application  to 
obtain  a  significant  portion  of  the  database  maintained  by  a  Mode  S  sensor  about  a  specific 
aircraft  in  coverage.  Some  of  this  data  parallels  the  sensor  surveillance  outputs  available  in 
ASTERIX  Category  048  (see  [5])  that  was  described  in  previous  sections  of  this  report. 

1.2.1  Aircraft  Report  Request 

The  ASTERIX  Category  018  request  message  for  an  aircraft  report  (message  type  11|6) 
contains  two  additional  data  items  beyond  the  common  ones  described  in  1.1.  These  two  data 
items  provide  a  way  to  tailor  the  request  to  limit  the  aircraft  data  in  the  response  to  only  what  is 
required  by  the  application  generating  the  request.  This  appendix  will  only  consider  those 
elements  useful  for  ELS/EHS  monitoring  and  validation.  (See  [16]  for  the  complete  definition  of 
the  aircraft  report  request/response  messages.) 

1.2. 1.1  Aircraft  Data  Link  Command 

The  ASTERIX  Category  018  Aircraft  Data  Link  Command  (Data  Item  007)  provides  a 
means  for  the  application  to  enable  or  disable  data  link  communications  flows  to  or  from  a 
specific  aircraft.  Data  Item  007  consists  of  one  byte.  The  high-order  four  bits  of  the  byte  are 
used  as  Boolean  flags,  and  the  low-order  bits  are  reserved  and  should  be  set  to  zero.  The 
ELS/EHS  monitoring  and  validation  function  utilizes  both  uplink  and  downlink  data  flows,  so 
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both  should  be  enabled  at  all  times  for  aircraft  of  interest.  Hence,  the  default  value  for  this  data 
item  for  ELS/EHS  monitoring  and  validation  applications  should  be  F0)6  (all  flag  bits  are  set). 

1.2. 1.2  Aircraft  Data  Link  Report  Request 

The  ASTERIX  Category  018  Aircraft  Data  Link  Report  Request  (Data  Item  009)  provides 
a  means  to  tailor  the  particular  request  to  include  only  the  items  of  interest  to  the  requestor.  Data 
Item  009  consists  of  a  one  required  byte  with  a  second  extension  byte  if  necessary.  Each  byte  is 
composed  of  a  series  of  Boolean  flag  bits  -  each  flag  bit  indicates  the  desired  response  for  a 
particular  piece  of  data  about  the  aircraft.  Setting  a  flag  bit  to  1  indicates  that  the  particular  data 
is  to  be  included  in  the  response.  The  low-order  bit  of  each  byte  of  Data  Item  009  flags  whether 
an  extension  byte  is  required  or  not.  The  ELS/EHS  monitoring  and  validation  application  will 
require  data  flags  in  both  bytes  of  Data  Item  009,  so  the  extension  bit  is  set  in  the  first  byte  and 
cleared  in  the  second  byte.  Only  those  flag  bits  corresponding  to  data  useful  in  the  ELS/EHS 
monitoring  and  validation  application  will  be  described  here.  (See  [15]  for  the  complete 
definition  of  Data  Item  009.) 

Table  I-2(a)  describes  the  flag  bits  in  the  first  byte  of  Data  Item  009,  while  Table  I-2(b) 
describes  the  flag  bits  in  the  second  byte  of  Data  Item  009.  The  not  applicable  indication  is  used 
for  data  that  is  not  useful  for  the  ELS/EHS  monitoring  and  validation  application.  Further 
information  about  the  data  elements  used  for  ELS/EHS  monitoring  and  validation  will  be 
discussed  as  part  of  the  Aircraft  Data  Link  Response  message  in  Section  1.2.2. 


Table  l-2(a) 

ASTERIX  Category  018  Data  Item  009  (Byte  1) 


Bit  Number 

Description 

Equivalent  Data  Item 
in  ASTERIX 
Category  048 

8 

Not  applicable 

— 

7 

Transponder  Capability  (CA) 

230 

6 

Transponder  Extended  Capability  (Register 

10)6  contents) 

5 

Aircraft  Coverage  Quality  Factor  (Flight 
Status) 

230 

4 

Not  applicable 

— 

3 

Aircraft  Position  in  Polar  Coordinates 

040 

2 

Aircraft  Position  in  Cartesian  Coordinates 

042 

1 

Extension  to  second  byte  (=1) 

— 
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Table  l-2(b) 


ASTERIX  Category  018  Data  Item  009  (O 

ptional  Byte  2) 

Bit  Number 

Description 

Equivalent  Data  Item  in 
ASTERIX  Category  048 

8 

Aircraft  Identification 

240 

7 

Mode  3/A  Code 

080 

6 

Aircraft  Ground  Speed 

200 

5 

Aircraft  Altitude 

100 

4 

Aircraft  Ground  Track  Angle 

200 

3 

Reserved  (=0) 

— 

2 

Reserved  (=0) 

— 

1 

Extension  to  second  byte  (=0) 

— 

1.2.2  Aircraft  Data  Link  Report  Response 

The  Mode  S  sensor  generates  an  Aircraft  Data  Link  Report  response  message  (message 
type  10|6)  in  response  to  a  request  message  (Section  1.2.1).  In  addition  to  the  common  data  items 
described  in  Section  1.1,  the  response  message  contains  an  indication  of  aircraft  data  link  status 
and  zero  or  more  additional  items  as  requested.  Those  response  items  applicable  to  the  ELS/EHS 
monitoring  and  validation  application  will  be  described  here.  (See  [16]  for  the  complete 
definition  of  the  ASTERIX  Category  018  Aircraft  Data  Link  Response  message.) 

1.2.2. 1  Aircraft  Data  Link  Status 

The  ASTERIX  Category  018  Aircraft  Data  Link  Status  (Data  Item  008)  consists  of  a  one 
required  byte  with  a  second  extension  byte  if  necessary.  Each  byte  is  composed  of  a  series  of 
Boolean  flag  bits.  The  low-order  bit  of  each  byte  of  Data  Item  008  flags  whether  an  extension 
byte  is  required  or  not.  Tables  I-3(a)  describes  the  flag  bits  in  the  first  byte  of  Data  Item  008, 
while  Table  I-3(b)  describes  the  flag  bits  in  the  second  (optional)  byte  of  Data  Item  008. 

Note  in  particular  bit  2  of  the  first  byte  of  Data  Item  008.  When  this  bit  is  set,  it  indicates 
that  the  particular  aircraft  in  the  request  is  no  longer  in  the  coverage  of  the  Mode  S  sensor 
receiving  the  request.  This  is  one  mechanism  that  an  application  using  ASTERIX  Category  018 
can  determine  that  an  aircraft  track  has  been  dropped.  ASTERIX  Category  018  does  not  provide 
a  track  drop  message  equivalent  to  that  described  in  Table  H-8. 
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Table  l-3(a) 

ASTERIX  Category  018  Data  Item  008  (Byte  1) 


Bit  Number 

Description 

Values 

8 

Uplink  Data  Frames 

0=enabled,  l=disabled 

7 

Extract  Uplink  Frames 

0=enabled,  l=disabled 

6 

Current  Uplink  Status 

0=enabled,  l=disabled 

5 

Current  Downlink  Status 

0=enabled,  l=disabled 

4 

Reserved 

0 

3 

Reserved 

0 

2 

Aircraft  in  Sensor  Coverage 

0=in  coverage,  1  =out  of  coverage 

1 

Extend  to  Second  Byte 

0=no  extension,  l=extension 

Table  l-3(b) 

ASTERIX  Category  018  Data  Item  008  (Optional  Byte  2) 

Bit  Number 

Description 

Values 

8 

Uplink/Downlink  Changeable 
via  Data  Link  Command 

0=enabled,  l=disablcd 

7 

Reserved 

0 

6 

Reserved 

0 

5 

Reserved 

0 

4 

Reserved 

0 

3 

Reserved 

0 

2 

Reserved 

0 

1 

Extend 

0 

1.2.2.2  Transponder  Capability 

If  bit  7  in  the  first  byte  of  Data  Item  009  of  the  Aircraft  Data  Link  Report  request  (see  Table 
I-2(a))  was  set  to  1,  then  the  response  will  contain  ASTERIX  Category  018  Data  Item  010.  This 
one-byte  field  contains  the  transponder  capability  (CA)  field  for  the  specified  aircraft.  (See 
Section  2.1  of  this  report  for  the  use  of  the  CA  value  in  ELS/EHS  monitoring  and  validation 
applications.) 

1. 2.2.3  Transponder  Extended  Capability  Report 

If  bit  6  in  the  first  byte  of  Data  Item  009  of  the  Aircraft  Data  Link  Report  request  (see  Table 
I-2(a))  was  set  to  1,  then  the  response  will  contain  ASTERIX  Category  018  Data  Item  Oil.  This 
seven-byte  field  contains  the  56-bit  contents  extracted  from  the  aircraft  Mode  S  transponder’s 
Data  Link  Capability  Report  (register  10|6).  (See  Section  2.4  for  the  use  of  the  extended 
capability  report  in  ELS/EHS  monitoring  and  validation  applications.) 
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1. 2. 2. 4  Aircraft  Position  in  Polar  Coordinates 

If  bit  3  in  the  first  byte  of  Data  Item  009  of  the  Aircraft  Data  Link  Report  request  (see  Table 
I-2(a))  was  set  to  1,  then  the  response  will  contain  ASTERIX  Category  018  Data  Item  014.  This 
data  is  equivalent  to  ASTERIX  Category  048  Data  Item  040.  The  first  16  bits  of  the  data  item 
contains  the  slant  range  with  an  LSB  of  1 /256th  of  a  nautical  mile.  The  second  16-bits  of  the  data 
item  contains  the  aircraft  azimuth  measured  with  respect  to  geographic  north.  The  LSB  of  the 
azimuth  is  360/216  (about  0.0055  degrees). 

1.2.2. 5  Aircraft  Position  in  Cartesian  Coordinates 

If  bit  2  in  the  first  byte  of  Data  Item  009  of  the  Aircraft  Data  Link  Report  request  (see  Table 
I-2(a))  was  set  to  1,  then  the  response  will  contain  ASTERIX  Category  018  Data  Item  015.  This 
data  is  equivalent  to  ASTERIX  Category  048  Data  Item  042.  The  first  16  bits  of  the  data  item 
contains  the  signed  x-axis  position  with  an  LSB  of  l/256lh  of  a  nautical  mile.  The  second  16-bits 
of  the  data  item  contains  the  signed  y-axis  position.  Negative  values  are  expressed  in  2’s- 
complement  form. 

1. 2. 2. 6  Aircraft  Identification 

If  bit  8  in  the  optional  second  byte  of  Data  Item  009  of  the  Aircraft  Data  Link  Report 
request  (see  Table  I-2(b>)  was  set  to  1,  then  the  response  will  contain  ASTERIX  Category  018 
Data  Item  031.  This  data  is  equivalent  to  ASTERIX  Category  048  Data  Item  240.  The  seven 
bytes  of  this  data  item  contain  the  56-bit  contents  of  the  Mode  S  transponder’s  Aircraft 
Identification  (register  20|6).  (See  Section  5  of  this  report  for  the  use  of  the  Aircraft  Identification 
in  ELS/EHS  monitoring  and  validation.) 

1.2.2. 7  Aircraft  Mode  3/A  Identity  Code 

If  bit  7  in  the  optional  second  byte  of  Data  Item  009  of  the  Aircraft  Data  Link  Report 
request  (see  Table  I-2(b))  was  set  to  1,  then  the  response  will  contain  ASTERIX  Category  018 
Data  Item  032.  This  data  is  equivalent  to  ASTERIX  Category  048  Data  Item  070.  The  two  bytes 
of  this  data  item  contain  the  12-bit  contents  of  the  Mode  S  transponder’s  reported  Mode  3/A 
identity  code.  (See  Section  4  for  the  use  of  the  Aircraft  Mode  3/A  Identity  Code  in  ELS/EHS 
monitoring  and  validation.) 

1. 2.2.8  A  ire  raft  A  Ititude 

If  bit  5  in  the  optional  second  byte  of  Data  Item  009  of  the  Aircraft  Data  Link  Report 
request  (see  Table  I-2(b))  was  set  to  1,  then  the  response  will  contain  ASTERIX  Category  018 
Data  Item  100.  This  data  is  equivalent  to  ASTERIX  Category  048  Data  Item  090.  The  two  bytes 
of  this  data  item  contain  the  14-bit  contents  of  the  Mode  S  transponder’s  reported  Mode  C 
altitude.  The  LSB  of  the  altitude  is  25  feet,  regardless  of  whether  the  aircraft  reports  in  25  or 
100-foot  quantization. 
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1.2.2. 9  Aircraft  Speed 


If  bit  6  in  the  optional  second  byte  of  Data  Item  009  of  the  Aircraft  Data  Link  Report 
request  (see  Table  I-2(b))  was  set  to  1,  then  the  response  will  contain  ASTER1X  Category  018 
Data  Item  034.  This  data  is  also  contained  in  ASTERIX  Category  048  Data  Item  200.  The  two 
bytes  of  this  data  item  contain  the  tracked  ground  speed  of  the  aircraft.  The  LSB  of  the  ground 
speed  value  is  2‘14  knots  (about  0.22  knots). 

1.2.2.10  Aircraft  Ground  Track  Angle 

If  bit  4  in  the  optional  second  byte  of  Data  Item  009  of  the  Aircraft  Data  Link  Report 
request  (see  Table  I-2(b))  was  set  to  1,  then  the  response  will  contain  ASTERIX  Category  018 
Data  Item  035.  This  data  is  also  contained  in  ASTERIX  Category  048  Data  Item  200.  The  two 
bytes  of  this  data  item  contain  the  ground  track  angle  of  the  aircraft  measured  with  respect  to 
geographic  north.  The  LSB  of  the  track  angle  value  is  360/2 16  degrees  (about  0.0055  degrees). 

1.3  GICB  Extraction  (Data  Link) 

ASTERIX  Category  018  provides  a  request-response  protocol  that  allows  an  application 
(e.g.,  ELS/EHS  monitoring  and  validation)  to  obtain  the  contents  of  selected  aircraft  GICB 
registers.  This  protocol  is  similar  in  function  to  the  FAA’s  Mode  S  sensor  communication 
interface  described  in  Appendix  H. 

The  ASTERIX  Category  018  protocol  not  only  provides  a  single  request-response  protocol, 
but  it  also  provides  a  means  for  a  single  request  to  generate  periodic  extractions  of  a  given 
register  from  a  given  aircraft  with  a  selectable  update  period.  A  periodic  request  repeats  until  it  is 
(1)  cancelled  by  a  GICB  Extraction  Cancellation  (see  1.3.4),  or  (2)  the  extraction  request  fails 
(e.g.,  the  selected  aircraft  has  flown  out  of  the  sensor  coverage). 

Each  of  the  ASTERIX  Category  018  GICB  extraction  protocol  messages  includes  the 
common  data  items  described  in  1.1.  In  addition,  each  of  the  GICB  extraction  messages  includes 
a  32-bit  GICB  number  (Data  Item  025).  This  GICB  number  provides  the  means  to  match  up  the 
application’s  request  with  the  Mode  S  sensor’s  later  responses.  The  application  should  increment 
the  GICB  number  for  each  request  it  makes. 

1.3.1  GICB  Extraction  Request 

The  ASTERIX  Category  018  GICB  Extraction  Request  message  (message  type  40i6)  is 
used  by  an  application  to  request  the  extraction  of  a  selected  Mode  S  transponder  GICB  register 
from  a  selected  aircraft.  The  message  includes  the  common  data  items  (see  1.1)  and  the  GICB 
number  (Data  Item  025)  -  which  should  be  incremented  for  each  new  request  generated  by  the 
application.  Each  GICB  Extraction  Request  message  also  includes  Data  Item  027  -  the  8-bit 
BDS  register  selector. 

The  ASTERIX  Category  018  GICB  Extraction  Request  message  may  contain  two  optional 
data  items.  Data  Item  028,  the  GICB  Extraction  Periodicity,  is  included  in  the  GICB  Extraction 
Request  if  more  than  one  response  to  the  request  is  desired.  Data  Item  028  occupies  16  bits  -  its 
value  expresses  the  desired  extraction  period  in  seconds.  A  periodicity  value  of  zero  defaults  to 
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the  minimum  extraction  period  available  from  the  Mode  S  sensor  (typically  one  antenna  scan). 
Data  Item  030,  the  GICB  Properties,  provides  for  several  control  functions  on  GICB  extraction. 
Table  1-4  describes  the  make-up  of  the  16-bit  contents  of  Data  Item  030.  Individual  GICB 
extraction  requests  can  be  prioritized  using  this  data  item.  The  extracted  GICB  register  contents 
can  be  sent  to  the  application  via  the  data  link  (Category  018)  protocol,  by  the  surveillance 
(Category  048)  protocol  (described  in  Section  1.4  of  this  report),  or  both  ways.  Note:  if  Data 
Item  030  is  not  included  in  a  GICB  Extraction  Request,  then  the  default  values  from  Table  1-4  are 
assumed. 


Table  1-4 

ASTERIX  Category  018  Data  Item  030  (GICB  Properties) 


Bits 

Description 

Default 

12-16 

Request  Priority  (0  is  lowest,  3 1  highest) 

8 

9-11 

Reserved,  set  to  zero 

— 

8 

l=periodicify  must  be  strictly  respected 

0 

7 

1=GICB  extraction  sent  if  required  by  an  external 
condition,  even  if  periodicity  not  respected 

0 

6 

l=Disable  periodic  extraction  attempts 

0 

4-5 

=00  Send  GICB  data  only  on  data  link  interface, 

=01  Send  GICB  data  only  on  surveillance  interface, 

=  10  Send  GICB  data  on  both  interfaces, 

=  1 1  Undefined 

00 

1-3 

Reserved,  set  to  zero 

— 

Bit  6  of  ASTERIX  Category  018  Data  Item  030  should  be  set  to  one  only  if  bit  7  is  also  set 
to  one.  This  functionality  is  intended  for  ACAS  RA  extraction  where  there  may  be  multiple 
asynchronous  extractions  of  GICB  register  30i6. 

1.3.2  GICB  Extraction  Response 

The  ASTERIX  Category  018  GICB  Extraction  Response  message  (message  type  43 16)  is 
returned  from  the  Mode  S  sensor  in  response  to  a  GICB  Extraction  request  (see  1.3.1).  The  GICB 
Extraction  Response  message  includes  the  ASTERIX  Category  018  common  data  items  (see  1.1) 
as  well  as  the  GICB  number  of  the  corresponding  request  (Data  Item  025).  Data  Item  027 
contains  the  8-bit  BDS  code  identifying  the  particular  GICB  register.  Data  Item  002  contains  the 
24-bit  time  stamp  (UTC  time  since  midnight  with  an  LSB  of  1 28ths  of  a  second).  If  the  GICB 
Extraction  request  can  be  honored,  ASTERIX  Category  018  Data  Item  029  (56-bit  extracted 
contents  of  the  selected  transponder  register)  is  included  in  the  ASTERIX  Category  018  GICB 
Extraction  Response  Message. 

The  final  data  item  in  an  ASTERIX  Category  018  GICB  Extraction  Response  message  is 
the  8-bit  Result  code  (Data  Item  001).  The  result  code  is  subdivided  into  two  4-bit  fields.  The 
high-order  four  bits  of  Data  Item  001  (denoted  Cause  Code)  indicates  the  Mode  S  sensor’s 
reaction  to  the  application’s  request.  Table  1-5  describes  the  defined  values  for  the  Cause  Code. 
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Table  1-5 

ASTERIX  Category  018  Data  Item  001  Cause  Codes 


Cause  Code 

Description 

0 

Request  accepted  and  being  processed 

1 

Request  rejected 

2 

Request  cancelled  (response  to  cancellation  -  see  1.3.4) 

3 

Request  accepted  and  completed  -  response  contains  data 

4 

Request  processing  temporarily  delayed,  but  still  valid 

5 

Request  is  being  successfully  processed 

6 

Invalid  result 

7... 15 

Reserved 

The  low-order  four  bits  of  Data  Item  001  (denoted  Diagnostic)  provide  further  explanation 
for  the  Cause  Code.  For  example.  Diagnostic  value  1  indicates  that  the  reason  a  request  has  been 
rejected  is  that  the  desired  aircraft  is  not  in  the  Mode  S  sensor’s  coverage.  Table  1-6  describes  the 
Diagnostic  codes.  (Note:  not  all  of  these  diagnostics  are  applicable  to  the  ELS/EHS  monitoring 
and  validation  application.) 


Table  1-6 

ASTERIX  Category  018  Data  Item  001  Diagnostic  Codes 


Diagnostic  Code 

Description 

0 

No  diagnostic  available 

1 

Aircraft  not  in  sensor  coverage 

2 

Incorrect  aircraft  address 

3 

Unable  to  process  request  message  (syntax  error) 

4 

Insufficient  transponder  data  link  capability 

5 

Invalid  LV  field 

6 

Duplicate  GICB  number 

7 

Unknown  GICB  number 

8 

Connection  timer  (T3)  expired 

9 

Interface  timer  (I/R)  expired 

10 

Uplink  flow  disabled 

1 1 ...  1 5 

Reserved 
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1.3.3  GICB  Extraction  Request  Acknowledgement 

The  ASTERIX  Category  018  GICB  Extraction  Request  Acknowledgement  message 
(message  type  42 16)  is  returned  from  the  Mode  S  sensor  in  response  to  a  GICB  Extraction  request 
(see  1.3.1)  in  order  to  indicate  the  immediate  status  of  the  corresponding  request.  This  might 
occur  when  the  request  was  to  start  a  periodic  extraction  where  the  first  response  might  take  many 
seconds,  or  it  might  occur  when  the  request  cannot  be  honored  due  to  some  error  condition  (e.g., 
selected  aircraft  not  in  coverage  of  the  sensor,  the  request  message  syntax  is  faulty,  the  aircraft 
does  not  have  the  capability  to  respond  to  the  request). 

The  GICB  Extraction  Request  Acknowledgement  message  includes  the  ASTERIX 
Category  018  common  data  items  (see  1.1)  as  well  as  the  GICB  number  of  the  corresponding 
request  (Data  Item  025).  It  also  includes  the  Result  code  (ASTERIX  Category  018  Data  Item 
001)  as  described  in  1.3.2  (Tables  1-5  and  1-6)  of  this  appendix. 

1.3.4  GICB  Extraction  Cancellation 

The  ASTERIX  Category  018  GICB  Extraction  Cancellation  message  (message  type  41  i6)  is 
used  to  terminate  an  ongoing  periodic  extraction  request.  The  GICB  number  (Data  Item  025) 
identifies  which  prior  request  is  to  be  cancelled.  The  GICB  Extraction  Cancellation  message  will 
cause  a  GICB  Extraction  Request  Acknowledgement  (see  1.3.3)  to  be  generated. 

1.4  Downlink  Broadcast 

As  was  noted  in  Appendix  H  (Section  2.2.6)  for  the  FAA’s  Mode  S  sensor  communication 
interface  protocol,  the  request/response  protocol  employed  by  ASTERIX  Category  018  requires 
that  the  application  know  the  Mode  S  address  of  the  target  aircraft  prior  to  making  any  request. 
The  application  discovers  what  aircraft  addresses  are  in  coverage  by  monitoring  the  downlink 
broadcast  messages  that  come  from  the  aircraft  when  it  enters  sensor  coverage.  Data  Item  005  in 
the  downlink  broadcast  message  provides  the  Mode  S  address  for  each  aircraft.  Failure  of  a 
request  for  this  aircraft  address  due  to  out  of  coverage  status  (see  1.2.2. 1,  1.3.2,  and  1.3.3) 
indicates  that  the  aircraft  is  no  longer  visible  to  the  Mode  S  sensor. 

In  addition  to  the  common  Data  Items  described  in  1.1,  an  ASTERIX  Category  018 
downlink  broadcast  message  (message  type  34|6)  contains  a  time-of-day  stamp  (Data  Item  002) 
and  the  broadcast  data  MB  field  (Data  Item  023).  The  time  stamp  in  Data  Item  002  contains  the 
UTC  time  since  midnight  in  a  three-byte  field.  The  LSB  for  time  is  1/1 28th  of  a  second.  The 
seven  bytes  of  Data  Item  023  contain  the  56  bits  of  the  downlink  broadcast  message  MB  data 
field.  (See  [1  ]  for  the  complete  definition  of  Mode  S  broadcast  messages.) 

1.5  Format  Summary 

Table  1-7  summarizes  the  usage  of  ASTERIX  Category  018  Data  Items  in  the  subset  of 
messages  used  in  ELS/EHS  monitoring  and  validation  applications  as  described  in  this  appendix. 
The  Data  Items  are  listed  in  numerical  order.  Data  Items  required  for  a  particular  message  type 
arc  denoted  ‘R’.  Data  Items  optional  for  a  particular  message  type  are  denoted  ‘O’.  Data  Items 
in  a  response  message  that  are  selectable  via  the  corresponding  request  message  are  denoted  ‘S’. 
Data  Items  that  are  not  valid  in  a  particular  message  type  are  denoted  The  hexadecimal 
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values  for  Data  Item  000  (the  message  type)  are  put  in  the  table  since  this  Data  Item  is  required 
for  every  ASTER1X  Category  018  message  type. 

Table  1-7 


ASTERIX  Category  018  Message  Summary  (for  ELS/EHS  applications) 


Data 

Item 

Aircraft 

Report 

Resp. 

Aircraft 

Report 

Request 

Downlink 

Broadcast 

GICB 

Extract 

Request 

GICB 

Extract 

Response 

GICB 

Extr. 

Ack. 

GICB 

Cancel 

000 

10i6 

H.6 

34,6 

40l6 

43,6 

42,6 

41  16 

001 

— 

— 

— 

— 

R 

— 

R 

002 

— 

— 

R 

O 

R 

— 

-- 

005 

R 

R 

R 

R 

R 

R 

R 

007 

— 

R 

— 

— 

— 

— 

— 

008 

R 

-- 

— 

— 

— 

-- 

— 

009 

S 

— 

-- 

— 

— 

— 

— 

010 

S 

— 

-- 

— 

— 

-- 

— 

011 

S 

— 

— 

— 

— 

— 

— 

012 

S 

— 

-- 

— 

— 

-- 

— 

013 

S 

— 

— 

— 

— 

— 

-- 

014 

S 

— 

— 

— 

— 

— 

— 

015 

S 

— 

-- 

— 

— 

-- 

— 

023 

— 

— 

R 

— 

— 

-- 

— 

027 

— 

— 

— 

R 

R 

— 

— 

031 

s 

— 

— 

— 

-- 

— 

— 

032 

s 

— 

— 

— 

— 

— 

— 

033 

s 

— 

— 

— 

— 

-- 

— 

034 

s 

— 

— 

— 

— 

— 

-- 

035 

s 

— 

-- 

— 

-- 

— 

— 

036 

R 

R 

R 

R 

R 

R 

R 

037 

R 

R 

R 

R 

R 

R 

R 

A 
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APPENDIX  J 

DERIVATION  OF  THE  INTERMEDIATE  TERMS  FOR  THRESHOLD 
VALIDATION  CALCULATIONS 


Section  3.1  presented  the  master  equation  used  for  the  conversion  of  the  surveillance 
radar’s  defined  error  variances  (sigmas)  in  position  determination  (in  polar  range/azimuth 
coordinates)  into  the  alternative  Cartesian  coordinate  system.  This  equation  (10-23  from  [4])  is 
repeated  here.  Figure  3-1  illustrated  how  the  error  ellipse  for  a  surveillance  radar  position  relates 
to  the  Cartesian  coordinate  system.  Variance  terms  (sigma  squared)  can  be  directly  added  as 
indicated  in  the  master  equation: 


This  appendix  will  detail  how  the  master  equation  was  used  in  Section  3.3  of  this  report  to  derive 
the  equations  for  the  Cartesian  error  variances.  Similar  derivations  would  be  used  for  the 
calculation  of  heading  (Section  3.4)  and  speed  (Section  3.5)  error  variances. 

It  should  be  noted  that  while  the  radar  reports  slant  range,  the  computations  performed  in 


Section  3  and  also  in  this  appendix  employ  ground  range.  Ground  range  is  derived  from  the 
reported  slant  range  and  altitude  as  follows: 


* g round  =  -\Kw2  “  Altitude2 


If  the  altitude  is  greater  than  the  slant  range  (or  if  no  altitude  value  is  available),  then  an  altitude 
of  half  the  slant  range  or  0.5  nautical  miles  is  assumed  (whichever  is  smaller)  in  the  calculation  of 
ground  range  as  described  in  Section  3.3.  From  here  on  in  this  appendix,  ground  range  will 
be  expressed  simply  as  R  and  azimuth  simply  as  6. 

Conversion  of  polar  coordinates  using  the  radar  azimuth  angular  convention  (angles 
measured  clockwise  from  north)  is  performed  using  the  equations  from  Section  3.3  and  repeated 
here: 


X  =  R  sin# 
Y  =  RcosO 


% 


125 


Applying  the  master  equation  for  this  case  involves  computing  the  partial  derivatives  for  the 
Cartesian  X  and  Y  coordinates  in  terms  of  their  polar  equivalents  R  and  0: 


—  =  —(Rs'mG)  =  sin# 
cR  31 

—  =  —(RcosG)  =  cos  # 
cR  cR 

'yy  n 

—  =  — (i?sin#)  =  R  cos# 
dG  dG 

—  =  — ( R  cos# )  =  -Rs'mG 
dG  dG 

Applying  the  master  equation  for  the  variation  a  in  x  position  where  the  a  values  in  range  and 
azimuth  are  known  parameters  of  the  surveillance  radar  yields: 

=  [<V  (f  )2  y  [<V  (f  )2  ]=  [<V  (sin  #)2  ]f  [<V  (R  cos  #)2  ] 


An  equivalent  derivation  for  the  y  coordinate  yields: 

°V2=  £v(§)]=  [o-R2(cos#)2]+[cr/(/?sin#)2] 


The  calculations  for  the  threshold  sigma  values  of  heading  (Section  3.4)  and  speed 
(Section  3.5)  also  require  the  cross  term  aXy  value.  Using  the  master  equation  again  yields: 


dL£LA-rr  2  _l  rr  2  (£L£L  + 

cRcR~TU6  <?0<?0-rURO\cRcOn~McR) 


The  third  term  on  the  right  side  of  this  equation  is  zero  because  the  surveillance  radar's 
measurement  variances  in  the  range  and  azimuth  directions  are  independent.  Expanding  the 
partial  derivatives  as  shown  above  yields: 

a  xy2  =  <jr2  (sin  #)(cos#)+cr02  (R  cos  #)(-^sin#) 

A  bit  of  algebra  yields  the  final  equation  shown  in  Section  3.3. 

=  \^r  ~  /fo’/Jsintfcos# 


A 
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ACRONYMS 


ACAS 

Airborne  Collision  Avoidance  Equipment 

ADS-B 

Automatic  Dependent  Surveillance  via  Broadcast 

ASTERIX 

All-purpose  Structured  Eurocontrol  Radar  Information  Exchange 

ATC 

Air  Traffic  Control 

*  BDS 

Mode  S  Comm-B  Data  Selector 

CA 

Mode  S  Transponder  Capability 

CAS 

» 

CD-2 

Calibrated  Airspeed 

Common  Digitizer  version  2 

CC1TT 

Comite  Consultatif  Internationale  de  Telegraphie  et  Telephonic 

DCE 

Data  Circuit  Terminating  Equipment 

DF 

Downlink  Format 

DME 

Distance  Measuring  Equipment 

DTE 

Data  Terminal  Equipment 

EHS 

Enhanced  Surveillance 

ELS 

FAA 

Elementary  Surveillance 

Federal  Aviation  Administration 

FCU 

Flight  Control  Unit 

FMS 

Flight  Management  System 

FS 

Flight  Status 

GICB 

Ground-Initiated  Comm-B 

GPS 

Global  Positioning  System 

IAS 

Indicated  Airspeed 

ICAO 

International  Civil  Aviation  Organization 

INS 

Inertial  Navigation  System 

ISA 

International  Standard  Atmosphere 

LAPB 

Link  Access  Protocol  -  Balanced 

•  LSB 

Least  Significant  Bit 

MB 

Comm-B  Data 

MCP 

% 

RA 

Mode  Control  Panel 

ACAS  Resolution  Advisory 

SAC 

System  Area  Code 

SIC 

System  Identification  Code 

SPI 

Special  Position  Indicator 

TA 

ACAS  Traffic  Advisory 

TAS 

True  Airspeed 
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ACRONYMS  (Continued) 


TIS 

USAF 

VOR 


Traffic  Information  Service 
United  States  Air  Force 
VHF  Omni-directional  Range 
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